From report at bugs.python.org  Sun Oct  1 01:16:59 2017
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Sun, 01 Oct 2017 05:16:59 +0000
Subject: [issue31651] io.FileIO cannot write more than 2GB (-4096) bytes???
 must be documented (if not fixed)
In-Reply-To: <1506805087.57.0.213398074469.issue31651@psf.upfronthosting.co.za>
Message-ID: <1506835019.76.0.213398074469.issue31651@psf.upfronthosting.co.za>


Yaroslav Halchenko <yarikoptic at gmail.com> added the comment:

Thank you for the follow-ups!  

Wouldn't it be better if Python documentation said exactly that 

On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes 
actually transferred.  (This is true on both 32-bit and 64-bit 
systems.)

Also, it might be nice to add a note on top, that this module is for 'low level' IO interface, and that it is recommended to use regular file type for typical file operations (not io.FileIO) to avoid necessity of dealing limitations such as the one mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31651>
_______________________________________

From report at bugs.python.org  Sun Oct  1 02:11:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 06:11:04 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1506838264.56.0.213398074469.issue31653@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Looks reasonable to me. Do you want to provide a patch Daniel?

----------
components: +Extension Modules -Library (Lib)
keywords: +easy (C)
nosy: +davin, pitrou, serhiy.storchaka
stage:  -> needs patch
type:  -> enhancement
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Sun Oct  1 02:36:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 06:36:42 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
Message-ID: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Usually non-string keyword names are rejected.

>>> def f(**kwargs): pass                                                                                                                                                                                                                    
...                                                                                                                                                                                                                                          
>>> f(**{0:0})
Traceback (most recent call last):                                                                                                                                                                                                           
  File "<stdin>", line 1, in <module>                                                                                                                                                                                                        
TypeError: f() keywords must be strings                                                                                                                                                                                                      
>>> dict(**{0:0})
Traceback (most recent call last):                                                                                                                                                                                                           
  File "<stdin>", line 1, in <module>                                                                                                                                                                                                        
TypeError: keywords must be strings                                                                                                                                                                                                          

There are checks in multiple places that satisfy this: in _PyEval_EvalCodeWithName(), PyArg_ValidateKeywordArguments(), PyArg_ParseTupleAndKeywords(), etc.

But SimpleNamespace is an exception.

>>> from types import SimpleNamespace
>>> SimpleNamespace(**{0:0})
namespace()

Non-string keys are omitted in the repr. Wouldn't be better to add also the check that keyword names for SimpleNamespace constructor are strings?

I don't know how classify this issue, as a bug or an enhancement.

Based on the StackOverflow question: https://stackoverflow.com/questions/46164770/accepting-integers-as-keys-of-kwargs.

----------
components: Interpreter Core
messages: 303450
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: SimpleNamespace accepts non-string keyword names

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sun Oct  1 02:47:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 06:47:00 +0000
Subject: [issue31478] assertion failure in random.seed() in case the seed
 argument has a bad __abs__() method
In-Reply-To: <1505421226.31.0.0993536255685.issue31478@psf.upfronthosting.co.za>
Message-ID: <1506840420.23.0.213398074469.issue31478@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I agree that a backport is still desirable.

Your plan LGTM. Implement __abs__ raising an exception (test both int ant long subclasses). Make sure that no error is raised. Make sure that random() returns the same value as when seeding with an exact int and long.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31478>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:30:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 08:30:32 +0000
Subject: [issue31651] io.FileIO cannot write more than 2GB (-4096) bytes???
 must be documented (if not fixed)
In-Reply-To: <1506805087.57.0.213398074469.issue31651@psf.upfronthosting.co.za>
Message-ID: <1506846632.8.0.213398074469.issue31651@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes 
> actually transferred.  (This is true on both 32-bit and 64-bit 
> systems.)

This is platform-depending limitation. It can be be changed in future. In addition, there are other causes of writing not all data (see `man 2 write`).

> Also, it might be nice to add a note on top, that this module is for 'low level' IO interface, and that it is recommended to use regular file type for typical file operations (not io.FileIO) to avoid necessity of dealing limitations such as the one mentioned.

This is not true for the module overall. And this is already documented for io.RawIOBase:

"""
Raw binary I/O typically provides low-level access to an underlying OS device or API, and does not try to encapsulate it in high-level primitives (this is left to Buffered I/O and Text I/O, described later in this page).
"""

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31651>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:37:53 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 08:37:53 +0000
Subject: [issue31336] Speed up _PyType_Lookup() for class creation
In-Reply-To: <1504525158.22.0.609539167408.issue31336@psf.upfronthosting.co.za>
Message-ID: <1506847073.14.0.213398074469.issue31336@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2102c789035ccacbac4362589402ac68baa2cd29 by Serhiy Storchaka (scoder) in branch 'master':
bpo-31336: Speed up type creation. (#3279)
https://github.com/python/cpython/commit/2102c789035ccacbac4362589402ac68baa2cd29


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31336>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:41:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 08:41:39 +0000
Subject: [issue31336] Speed up _PyType_Lookup() for class creation
In-Reply-To: <1504525158.22.0.609539167408.issue31336@psf.upfronthosting.co.za>
Message-ID: <1506847299.86.0.213398074469.issue31336@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Stefan! I had doubts about your initial (much simpler) changes, but changed my mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31336>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:41:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 08:41:49 +0000
Subject: [issue31336] Speed up _PyType_Lookup() for class creation
In-Reply-To: <1504525158.22.0.609539167408.issue31336@psf.upfronthosting.co.za>
Message-ID: <1506847309.93.0.213398074469.issue31336@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31336>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:43:26 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 01 Oct 2017 08:43:26 +0000
Subject: [issue31336] Speed up _PyType_Lookup() for class creation
In-Reply-To: <1504525158.22.0.609539167408.issue31336@psf.upfronthosting.co.za>
Message-ID: <1506847406.47.0.213398074469.issue31336@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Thanks for the reviews, and thank you for merging it, Serhiy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31336>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:44:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 08:44:38 +0000
Subject: [issue31465] Allow _PyType_Lookup() to raise exceptions
In-Reply-To: <1505376439.65.0.460485878995.issue31465@psf.upfronthosting.co.za>
Message-ID: <1506847478.1.0.213398074469.issue31465@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm positive to this change in general, but this is too complex and delicate code. In needs careful reviewing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31465>
_______________________________________

From report at bugs.python.org  Sun Oct  1 04:44:44 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 08:44:44 +0000
Subject: [issue31465] Allow _PyType_Lookup() to raise exceptions
In-Reply-To: <1505376439.65.0.460485878995.issue31465@psf.upfronthosting.co.za>
Message-ID: <1506847484.12.0.213398074469.issue31465@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -3632

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31465>
_______________________________________

From report at bugs.python.org  Sun Oct  1 05:49:11 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 09:49:11 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1506851351.79.0.213398074469.issue31653@psf.upfronthosting.co.za>


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


----------
type: enhancement -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Sun Oct  1 08:02:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 12:02:14 +0000
Subject: [issue31626] Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1506859334.23.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There several bugs in the memory allocator.

Incorrectly detected the case when realloc() resizes a memory block in-place. Wrong address is used for filling the extra memory with DEADBYTE.

-    if (q == oldq && nbytes < original_nbytes) {
+    if (q == oldq - 2*SST && nbytes < original_nbytes) {
         /* shrinking:  mark old extra memory dead */
-        memset(q + nbytes, DEADBYTE, original_nbytes - nbytes);
+        memset(q + 2*SST + nbytes, DEADBYTE, original_nbytes - nbytes);
     }

But fixing this exposes other problem. _PyMem_DebugRawRealloc() is called recursively. _PyMem_DebugRawRealloc calls api->alloc.realloc which is _PyMem_DebugRawRealloc. There are two nested debug allocators. The block is nested in other block, both have their own header and footer.

|header1|header2|------------------------------|footer2|footer1|

_PyMem_DebugRawRealloc fills the extra memory with DEADBYTE.

|header|---------------------------..unused..|footer|
|header|---------------------------|footer|XXXXXXXXX|

But in case of nested _PyMem_DebugRawRealloc's, the outer one (which reallocates the inner block), overwrites the footer of the outer block.

|header1|header2|--------------------..unused..|footer2|footer1|
|header1|header2|--------------------..unused|footer1|XXXXXXXXX| after inner realloc
|header1|header2|--------------------|footer2|YYYYYYYYY|XXXXXXX| after outher realloc

XXX are DEADBYTEs written by the inner allocator, YYY are DEADBYTEs written by the outer allocator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sun Oct  1 08:02:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 12:02:27 +0000
Subject: [issue31626] Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1506859347.95.0.213398074469.issue31626@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sun Oct  1 08:15:27 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 12:15:27 +0000
Subject: [issue31308] forkserver process isn't re-launched if it died
In-Reply-To: <1504103235.79.0.43802074293.issue31308@psf.upfronthosting.co.za>
Message-ID: <1506860127.02.0.213398074469.issue31308@psf.upfronthosting.co.za>


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

Looks like this will not make into 3.6.3.

I'd like to sum up the discussion a bit:
- I think at the very least least we must protect the forkserver against SIGINT, like the semaphore tracker already is
- I think it's beneficial to also restart it on demand if necessary
- I can't think of a use case where the user asks "no, please don't restart the forkserver on demand" as there is no way to start it manually anyway, and not restarting it breaks functionality

Also, bpo-31310 is a similar issue for the semaphore tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31308>
_______________________________________

From report at bugs.python.org  Sun Oct  1 08:21:26 2017
From: report at bugs.python.org (Safihre)
Date: Sun, 01 Oct 2017 12:21:26 +0000
Subject: [issue31555] Windows pyd slower when not loaded via load_dynamic
In-Reply-To: <1506111862.7.0.559365962543.issue31555@psf.upfronthosting.co.za>
Message-ID: <1506860486.59.0.213398074469.issue31555@psf.upfronthosting.co.za>


Safihre <safihre at sabnzbd.org> added the comment:

If you know the problem, would you also know the solution?
What is the difference in how they generate sys.path entries and how does this affect performance during execution of the module function?
Just want to understand what is going on :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31555>
_______________________________________

From report at bugs.python.org  Sun Oct  1 08:51:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 12:51:55 +0000
Subject: [issue31626] Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1506862315.63.0.213398074469.issue31626@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3825
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sun Oct  1 09:02:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 13:02:31 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1506862951.0.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Using nested _PyMem_DebugRawRealloc() looks suspicions to me. This may be a bug.

But even without nested _PyMem_DebugRawRealloc() writing to the extra memory after using realloc() looks wrong to me. This can break other non-trivial system allocators which write an information past the allocated block. This can cause a segfault if unused memory pages are returned to OS.

After creating the PR I have found that it literally restores the code of 2.7 and 3.3. 3.4 and later contain this bug. The bug looks enough serious to me for fixing it in 3.4 and 3.5.

----------
nosy: +larry
title: Crash in _PyUnicode_DecodeUnicodeEscape on OpenBSD -> Writing in freed memory in _PyMem_DebugRawRealloc() after shrinking a memory block
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sun Oct  1 09:51:06 2017
From: report at bugs.python.org (Oren Milman)
Date: Sun, 01 Oct 2017 13:51:06 +0000
Subject: [issue31478] assertion failure in random.seed() in case the seed
 argument has a bad __abs__() method
In-Reply-To: <1505421226.31.0.0993536255685.issue31478@psf.upfronthosting.co.za>
Message-ID: <1506865866.63.0.213398074469.issue31478@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
pull_requests: +3826

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31478>
_______________________________________

From report at bugs.python.org  Sun Oct  1 10:29:30 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Oct 2017 14:29:30 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1506868170.01.0.213398074469.issue31655@psf.upfronthosting.co.za>


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

Well, it would be an "unenhancement" (reducing functionality :).  

What I think it would be classed as is an API bug fix, and those generally can be made only in feature releases.  I can imagine code depending on this ability, since we have had code in the wild that depends on the ability to put non-string keys in an object's __dict__ even before SimpleNamespace existed.

(By the way, dir is broken if an object's __dict__ contains non-string keys.)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sun Oct  1 10:30:06 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Oct 2017 14:30:06 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1506868206.3.0.213398074469.issue31655@psf.upfronthosting.co.za>


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


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sun Oct  1 10:30:29 2017
From: report at bugs.python.org (Steve Dower)
Date: Sun, 01 Oct 2017 14:30:29 +0000
Subject: [issue31555] Windows pyd slower when not loaded via load_dynamic
In-Reply-To: <1506111862.7.0.559365962543.issue31555@psf.upfronthosting.co.za>
Message-ID: <1506868229.94.0.213398074469.issue31555@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I don't really care, since you're comparing multiple unsupported technologies, but my guess is that the egg install injects the library much earlier on sys.path, which avoids most of the relatively expensive file system scan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31555>
_______________________________________

From report at bugs.python.org  Sun Oct  1 10:31:42 2017
From: report at bugs.python.org (SilentGhost)
Date: Sun, 01 Oct 2017 14:31:42 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506822647.49.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <1506868302.22.0.213398074469.issue31654@psf.upfronthosting.co.za>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 10:33:56 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Oct 2017 14:33:56 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1506868436.63.0.213398074469.issue31655@psf.upfronthosting.co.za>


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

Sorry, not broken, it just raises a type error, which is appropriate :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sun Oct  1 11:01:16 2017
From: report at bugs.python.org (Matthias Gilch)
Date: Sun, 01 Oct 2017 15:01:16 +0000
Subject: [issue31656] Bitwise operations for bytes-type
Message-ID: <1506870076.79.0.213398074469.issue31656@psf.upfronthosting.co.za>


New submission from Matthias Gilch <matthias.gilch.mg+py at gmail.com>:

I've seen that the bytes type does not support bitwise operations, but I think users would expect that those operations will work.

----------
components: Interpreter Core
messages: 303464
nosy: MGilch
priority: normal
severity: normal
status: open
title: Bitwise operations for bytes-type
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31656>
_______________________________________

From report at bugs.python.org  Sun Oct  1 11:08:33 2017
From: report at bugs.python.org (diana)
Date: Sun, 01 Oct 2017 15:08:33 +0000
Subject: [issue31657] unit test for optimization levels does not cover
 __debug__ case
Message-ID: <1506870513.15.0.213398074469.issue31657@psf.upfronthosting.co.za>


New submission from diana <diana.joan.clarke at gmail.com>:

There are currently three supported optimization levels (0, 1, and 2). Briefly summarized, they do the following.

    0: no optimizations
    1: remove assert statements and __debug__ blocks
    2: remove docstrings, assert statements, and __debug__ blocks

The current compile() tests for optimization levels in Lib/test/test_builtin.py covers the assert and docstring cases, but it doesn't test that __debug__ code blocks are included or excluded based on the optimization level.

For example, if you change Python/compile.c to always include __debug__ blocks regardless of the optimization level, the existing compile() tests will continue to pass.

$ git diff Python/compile.c
diff --git a/Python/compile.c b/Python/compile.c
index 280ddc39e3..d65df098bb 100644
--- a/Python/compile.c
+++ b/Python/compile.c
@@ -4143,7 +4143,7 @@ expr_constant(struct compiler *c, expr_ty e)
         /* optimize away names that can't be reassigned */
         id = PyUnicode_AsUTF8(e->v.Name.id);
         if (id && strcmp(id, "__debug__") == 0)
-            return !c->c_optimize;
+            return 1;
         return -1;
     case NameConstant_kind: {
         PyObject *o = e->v.NameConstant.value;

----------
messages: 303465
nosy: diana
priority: normal
severity: normal
status: open
title: unit test for optimization levels does not cover __debug__ case
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31657>
_______________________________________

From report at bugs.python.org  Sun Oct  1 11:21:22 2017
From: report at bugs.python.org (diana)
Date: Sun, 01 Oct 2017 15:21:22 +0000
Subject: [issue31657] unit test for optimization levels does not cover
 __debug__ case
In-Reply-To: <1506870513.15.0.213398074469.issue31657@psf.upfronthosting.co.za>
Message-ID: <1506871282.44.0.213398074469.issue31657@psf.upfronthosting.co.za>


Change by diana <diana.joan.clarke at gmail.com>:


----------
keywords: +patch
pull_requests: +3827
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31657>
_______________________________________

From report at bugs.python.org  Sun Oct  1 11:30:52 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Oct 2017 15:30:52 +0000
Subject: [issue31656] Bitwise operations for bytes-type
In-Reply-To: <1506870076.79.0.213398074469.issue31656@psf.upfronthosting.co.za>
Message-ID: <1506871852.01.0.213398074469.issue31656@psf.upfronthosting.co.za>


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

What happens when you apply a bitwise operation to two bytes objects of unequal length?

Since the answer to that question is not obvious, we simply don't support the operation.

If you want to make a proposal for this the python-ideas mailing list would be the appropriate forum.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31656>
_______________________________________

From report at bugs.python.org  Sun Oct  1 11:52:50 2017
From: report at bugs.python.org (Jeffrey Rackauckas)
Date: Sun, 01 Oct 2017 15:52:50 +0000
Subject: [issue31553] Extend json.tool to handle jsonlines (with a flag)
In-Reply-To: <1506098466.58.0.224432895447.issue31553@psf.upfronthosting.co.za>
Message-ID: <1506873170.03.0.213398074469.issue31553@psf.upfronthosting.co.za>


Change by Jeffrey Rackauckas <jeffreyrack at gmail.com>:


----------
keywords: +patch
pull_requests: +3828
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31553>
_______________________________________

From report at bugs.python.org  Sun Oct  1 12:09:10 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Oct 2017 16:09:10 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1506874150.71.0.213398074469.issue31655@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Wouldn't be better to add also the check that keyword names
> for SimpleNamespace constructor are strings?

Yes.

> I don't know how classify this issue, as a bug or an enhancement.

It is arguably a bug fix.  +0 for putting this in Python 3.6.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sun Oct  1 12:56:08 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Oct 2017 16:56:08 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506876968.74.0.213398074469.issue31622@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 13:14:06 2017
From: report at bugs.python.org (Oren Milman)
Date: Sun, 01 Oct 2017 17:14:06 +0000
Subject: [issue21983] segfault in ctypes.cast
In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>
Message-ID: <1506878046.71.0.213398074469.issue21983@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

IMHO, Lib/ctypes/test/test_cast.py is the relevant test.

Mark, do you still wish to provide a fix for that?
(Otherwise, i would be happy to open a PR.)

----------
nosy: +Oren Milman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21983>
_______________________________________

From report at bugs.python.org  Sun Oct  1 13:19:48 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Oct 2017 17:19:48 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506822647.49.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <1506878388.13.0.213398074469.issue31654@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Compare-and-exchange is sufficient for avoiding the GIL contention
> I describe above.

If Python objects are involved, it is more complicated than you suggest.  Possibly, multiprocessing can offer a shared counter that creates integer objects on demand and that offers guaranteed atomic increments and decrements (as semaphores) do.

> one of the nice things about multiprocessing is avoiding 
> GIL-introduced latency!

The primary way it achieves this benefit is by avoiding shared state altogether.

----------
nosy: +davin, pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 13:34:52 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 17:34:52 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506879292.55.0.213398074469.issue31622@psf.upfronthosting.co.za>


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

> On a system with pthreads, the thread_id that Python provides is merely pthread_t casted to unsigned long. This works today, but is in violation of the standard, and could break on systems with exotic pthread_t.

I don't think that follows.  Even if pthread_t is not an integer, it does have a binary representation that can be trivially converted to a arbitrary-sized Python int in Python-facing APIs such as threading.get_ident().

(and similarly, of course, for converting in the other direction e.g. for pthread_kill())

> There is also the ability to introduce undefined behavior, such as sending a signal to an invalid thread id:

I wouldn't worry much about pthread_kill(), a little-used feature.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 13:45:59 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 17:45:59 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506822647.49.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <1506879959.94.0.213398074469.issue31654@psf.upfronthosting.co.za>


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

While the use case is reasonable (if specialized), I'm not sure ctypes is the place to expose such functionality, which can be quite extensive (see https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html). Perhaps as a separate package on PyPI?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 13:53:44 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Oct 2017 17:53:44 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506880424.68.0.213398074469.issue31630@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would have thought this would be a straight pass-through to the underlying hardware FPU tan() instruction so that it would give the same answer for the same hardware regardless of O/S.

Perhaps we're seeing a software-only implementation (using CORDIC or somesuch).  If so, inputs close to a singularity are the place where the implementation is likely to fall apart (the relative error in this example is 1.000004001955473).

* https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html
* https://stackoverflow.com/questions/16880376/sin-cos-tan-not-accurate
* http://code.activestate.com/recipes/576792-polar-to-rectangular-conversions-using-cordic/

----------
nosy: +rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct  1 13:55:33 2017
From: report at bugs.python.org (Daniel Colascione)
Date: Sun, 01 Oct 2017 17:55:33 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506878388.13.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <CAKOZuet1zUdC9JEmpuh+8wZrud2PGZ2khBuqMWBY0owwKoNHuQ@mail.gmail.com>


Daniel Colascione <dancol at google.com> added the comment:

On Oct 1, 2017 10:19 AM, "Raymond Hettinger" <report at bugs.python.org> wrote:

Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Compare-and-exchange is sufficient for avoiding the GIL contention
> I describe above.

If Python objects are involved, it is more complicated than you suggest.

Python objects are not involved. We're talking about memory manipulation on
the same level as ctypes.memmove.

Possibly, multiprocessing can offer a shared counter that creates integer
objects on demand and that offers guaranteed atomic increments and
decrements (as semaphores) do.

Why would it, when ctypes can provide generic functionality?

> one of the nice things about multiprocessing is avoiding
> GIL-introduced latency!

The primary way it achieves this benefit is by avoiding shared state
altogether.

Well, yes, but sometimes shared state is unavoidable, and it's best to
manipulate it as efficiently as possible.

----------
nosy: +davin, pitrou, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 14:04:41 2017
From: report at bugs.python.org (Daniel Colascione)
Date: Sun, 01 Oct 2017 18:04:41 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506879959.94.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <CAKOZuev0xgNHPVhCsNMFD1fHG3r3qNNcdaNBadMex1mUGMdYWA@mail.gmail.com>


Daniel Colascione <dancol at google.com> added the comment:

On Oct 1, 2017 10:46 AM, "Antoine Pitrou" <report at bugs.python.org> wrote:

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

While the use case is reasonable (if specialized),

It's not that specialized. You might want atomic updates for coordinating
with C APIs that expect callers to have this capability.

not sure ctypes is the place to expose such functionality, which can be
quite extensive (see https://gcc.gnu.org/onlinedocs/gcc/_005f_
005fatomic-Builtins.html).

You don't need to provide all of those builtins. Users can build them in
Python out of atomic-compare-and-exchange. Only compare and exchange needs
C support. It's not very much code.

Perhaps

as a separate package on PyPI?

I have little interest in a separate PyPI module. I don't want to have to
distribute custom-compiled extension modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 14:12:08 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 18:12:08 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <CAKOZuev0xgNHPVhCsNMFD1fHG3r3qNNcdaNBadMex1mUGMdYWA@mail.gmail.com>
Message-ID: <2eb01833-012e-5f40-6727-780d0750980d@free.fr>


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

Le 01/10/2017 ? 20:04, Daniel Colascione a ?crit?:
> 
> It's not that specialized. You might want atomic updates for coordinating
> with C APIs that expect callers to have this capability.

That does sound specialized to me :-) Can you give an example of such a
C API?

> You don't need to provide all of those builtins. Users can build them in
> Python out of atomic-compare-and-exchange. Only compare and exchange needs
> C support. It's not very much code.

I'm assuming you're suggesting to write a loop with an
atomic-compare-and-exchange.  Bytecode execution in CPython being slow,
it means you risk a lot more contention (and busy looping) than if the
primitive was written in C.  Perhaps even a semaphore would be faster :-)

> I have little interest in a separate PyPI module. I don't want to have to
> distribute custom-compiled extension modules.

Understood, but that's not enough of an argument to put something in the
standard library...

You might want to float your idea on python-ideas to see if you get
support from people who have a similar need:
https://mail.python.org/mailman/listinfo/python-ideas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 14:14:36 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 18:14:36 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506822647.49.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <1506881676.53.0.213398074469.issue31654@psf.upfronthosting.co.za>


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

Note that if there is already a C API to perform atomic ops, you can simply use ctypes to invoke that API.  Unfortunately, the aforementioned GCC builtins seem to be only available as intrinsics (at least I couldn't find a shared library that exposes the __atomic_* functions on my system).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 14:31:01 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 Oct 2017 18:31:01 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506882661.6.0.213398074469.issue31630@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm fairly sure most modern OSs on x86-64 use software implementations of sin, cos and tan. At least, I hope so: the x87 hardware versions are notoriously inaccurate:

https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct  1 14:32:38 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 01 Oct 2017 18:32:38 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506882758.75.0.213398074469.issue31630@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So actually, the cause of the inaccuracy here could be that OpenBSD _is_ using the hardware instructions ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:02:35 2017
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Oct 2017 19:02:35 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506884555.45.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Of course the relationship is extremely delicate near pi/2.  On my Windows Python 3:

>>> import math
>>> (1.5707963267948961).hex()
'0x1.921fb54442d16p+0'
>>> math.tan(float.fromhex('0x1.921fb54442d16p+0')) # what the test expects
1978937966095219.0
>>> math.tan(float.fromhex('0x1.921fb54442d15p+0')) # input 1 ulp less
1374823386397210.2
>>> math.tan(float.fromhex('0x1.921fb54442d17p+0')) # input 1 ulp more
3530114321217157.5

Interestingly, wxMaxima on the same box reproduces the OpenBSD result:

(%i1) tan(1.5707963267948961);
(%o1) 1.978945885716843*10^15

But I don't know how Maxima (or OpenBSD) implement tan().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:03:26 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 01 Oct 2017 19:03:26 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506884606.49.0.213398074469.issue31622@psf.upfronthosting.co.za>


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

You don't think having a function that takes an integer and dereferences it as memory is a bad idea?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:05:58 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 19:05:58 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506884758.63.0.213398074469.issue31622@psf.upfronthosting.co.za>


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

> You don't think having a function that takes an integer and dereferences it as memory is a bad idea?

I'm not sure what you're talking about.  What function is that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:07:10 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 01 Oct 2017 19:07:10 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506884758.63.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506884827.3579751.1124253528.4077A83D@webmail.messagingengine.com>


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

On Sun, Oct 1, 2017, at 12:05, Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> > You don't think having a function that takes an integer and dereferences it as memory is a bad idea?
> 
> I'm not sure what you're talking about.  What function is that?

signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on
https://github.com/python/cpython/pull/3756.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:15:08 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 19:15:08 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506884827.3579751.1124253528.4077A83D@webmail.messagingengine.com>
Message-ID: <9e711472-2fe0-ce7f-2a85-fc3e1bbf9d5e@free.fr>


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

Le 01/10/2017 ? 21:07, Benjamin Peterson a ?crit?:
> 
> signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on
> https://github.com/python/cpython/pull/3756

Given how specialized (and of little actual use) those functions are, I
don't think it's much of a problem if they misbehave if you deliberately
pass an invalid thread id.

At least it sounds less of a problem than breaking all code that expects
a thread id to be an integer.

(btw, pthread_getcpuclockid returns ESRCH on Linux if called with an
invalid thread id)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:17:30 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Oct 2017 19:17:30 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506885450.54.0.213398074469.issue31630@psf.upfronthosting.co.za>


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

OpenBSD reduces to the range [-pi/4,pi/4]:

   https://github.com/openbsd/src/blob/master/lib/libm/src/s_tan.c


According to the man page on i386:

   http://man.openbsd.org/FreeBSD-11.0/math.3

"Argument reduction is not performed accurately for huge arguments, resulting in large errors for such arguments to cos(), sin(), and tan()."


pi/2 is not exactly "huge", but it would be interesting if this
occurred on i386.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:20:54 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 01 Oct 2017 19:20:54 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <9e711472-2fe0-ce7f-2a85-fc3e1bbf9d5e@free.fr>
Message-ID: <1506885651.3582261.1124257520.61739A64@webmail.messagingengine.com>


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

On Sun, Oct 1, 2017, at 12:15, Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> Le 01/10/2017 ? 21:07, Benjamin Peterson a ?crit?:
> > 
> > signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on
> > https://github.com/python/cpython/pull/3756
> 
> Given how specialized (and of little actual use) those functions are, I
> don't think it's much of a problem if they misbehave if you deliberately
> pass an invalid thread id.

Okay, so you think this PR is reasonable?

> 
> At least it sounds less of a problem than breaking all code that expects
> a thread id to be an integer.

I suppose, though you can't usefully use it as an integer. I imagine a
comparable and hashable opaque object would be compatible with most
code.

> 
> (btw, pthread_getcpuclockid returns ESRCH on Linux if called with an
> invalid thread id)

More precisely, glibc has a heuristic check for thread id validity,
which dereferences whatever you pass in. It won't save you from
crashing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:25:55 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 19:25:55 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506885651.3582261.1124257520.61739A64@webmail.messagingengine.com>
Message-ID: <4ebc3b0d-aaa0-117d-136b-a01affb13d63@free.fr>


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

Le 01/10/2017 ? 21:20, Benjamin Peterson a ?crit?:
> 
>>> signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on
>>> https://github.com/python/cpython/pull/3756
>>
>> Given how specialized (and of little actual use) those functions are, I
>> don't think it's much of a problem if they misbehave if you deliberately
>> pass an invalid thread id.
> 
> Okay, so you think this PR is reasonable?

On the principle yes.  I am not interested enough in this feature to
look at the implementation.

Another possibility would be to have a new separate threading API
returning a "low-level opaque thread handle" that you could pass to
pthread_kill() and pthread_getcpuclockid().  threading.get_ident() could
still be used for logging purposes and others.

A related issue: what if you want to call pthread_kill() on a non-Python
thread?

> I suppose, though you can't usefully use it as an integer. I imagine a
> comparable and hashable opaque object would be compatible with most
> code.

What happens for code that uses e.g. "%x" to format thread ids?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:26:24 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 01 Oct 2017 19:26:24 +0000
Subject: [issue31634] Consider installing wheel in ensurepip by default
In-Reply-To: <1506677010.8.0.213398074469.issue31634@psf.upfronthosting.co.za>
Message-ID: <1506885984.79.0.213398074469.issue31634@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31634>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:34:10 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 01 Oct 2017 19:34:10 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <4ebc3b0d-aaa0-117d-136b-a01affb13d63@free.fr>
Message-ID: <1506886447.3585953.1124266472.6BD036B1@webmail.messagingengine.com>


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

On Sun, Oct 1, 2017, at 12:25, Antoine Pitrou wrote:
> Another possibility would be to have a new separate threading API
> returning a "low-level opaque thread handle" that you could pass to
> pthread_kill() and pthread_getcpuclockid().  threading.get_ident() could
> still be used for logging purposes and others.
> 
> A related issue: what if you want to call pthread_kill() on a non-Python
> thread?

C code that provides pthread_t to Python would have to wrap it.

> 
> > I suppose, though you can't usefully use it as an integer. I imagine a
> > comparable and hashable opaque object would be compatible with most
> > code.
> 
> What happens for code that uses e.g. "%x" to format thread ids?

It's okay for the opaque object to have a int() conversion. The
important part is that threading apis don't accept ints.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:42:26 2017
From: report at bugs.python.org (Daniel Colascione)
Date: Sun, 01 Oct 2017 19:42:26 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506881676.53.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <CAKOZuetTrjwW8iBuBu_c3ipH_7+oqL=HwAcgLHGLTkOjVA0E1w@mail.gmail.com>


Daniel Colascione <dancol at google.com> added the comment:

On Sun, Oct 1, 2017 at 11:14 AM, Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Note that if there is already a C API to perform atomic ops, you can
> simply use ctypes to invoke that API.  Unfortunately, the aforementioned
> GCC builtins seem to be only available as intrinsics (at least I couldn't
> find a shared library that exposes the __atomic_* functions on my system).
>

Right. I performed the same search. On Windows, at least
InterlockedCompareExchange is exported from kernel32.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 15:51:25 2017
From: report at bugs.python.org (Daniel Colascione)
Date: Sun, 01 Oct 2017 19:51:25 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <2eb01833-012e-5f40-6727-780d0750980d@free.fr>
Message-ID: <CAKOZuesfNpP-U4-61yxGfHPgROZZXG-FBiFWf=OY0Cxqid+6Lw@mail.gmail.com>


Daniel Colascione <dancol at google.com> added the comment:

On Sun, Oct 1, 2017 at 11:12 AM, Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le 01/10/2017 ? 20:04, Daniel Colascione a ?crit :
> >
> > It's not that specialized. You might want atomic updates for coordinating
> > with C APIs that expect callers to have this capability.
>
> That does sound specialized to me :-) Can you give an example of such a
> C API?
>

The Linux futex protocol, as described in man futex(7), comes to mind.
Maybe you want to manipulate C++ shared_ptr objects --- these objects also
rely on atomic operations. For these facilities, you need atomic operations
for *correctness*. Taking a mutex as an alternative is not an option
because there is no C-side mutex to take.

> > You don't need to provide all of those builtins. Users can build them in
> > Python out of atomic-compare-and-exchange. Only compare and exchange
> needs
> > C support. It's not very much code.
>
> I'm assuming you're suggesting to write a loop with an
> atomic-compare-and-exchange.  Bytecode execution in CPython being slow,
> it means you risk a lot more contention (and busy looping) than if the
> primitive was written in C.  Perhaps even a semaphore would be faster :-)
>

It's still faster than waiting several milliseconds for the GIL. Bytecode
isn't *that* slow --- according to ipython, this operation should take a
few hundred nanoseconds. Besides, in a JIT implementation, it'll be as fast
as native code.

>
> > I have little interest in a separate PyPI module. I don't want to have to
> > distribute custom-compiled extension modules.
>
> Understood, but that's not enough of an argument to put something in the
> standard library...
>
> You might want to float your idea on python-ideas to see if you get
> support from people who have a similar need:
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
I don't understand the opposition to this feature request. It's a trivial
amount of code (invoke a compiler intrinsic), makes the API more complete,
and addresses a real, specific use case as well as some other hypothetical
use cases. It costs nothing to add this functionality to the standard
library. The standard library already includes a whole web server and HTTP
client, a diff engine, various database engines, a facility for parsing
email, an NNTP client, a GUI system, and a facility for "determin[ing] the
type of sound [a] file". Why can the standard library include all of these
facilities and not a simple facility for performing a very common kind of
memory operation? Standard library support for this functionality is
essential, as it's not possible to implement in pure Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 16:51:11 2017
From: report at bugs.python.org (Craig Holmquist)
Date: Sun, 01 Oct 2017 20:51:11 +0000
Subject: [issue31658] xml.sax.parse won't accept path objects
Message-ID: <1506891071.57.0.213398074469.issue31658@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craigholm at gmail.com>:

>>> import xml.sax
>>> import pathlib
[...]
>>> xml.sax.parse(pathlib.Path('path/to/file'), handler)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/xml/sax/__init__.py", line 33, in parse
    parser.parse(source)
  File "/usr/lib/python3.6/xml/sax/expatreader.py", line 105, in parse
    source = saxutils.prepare_input_source(source)
  File "/usr/lib/python3.6/xml/sax/saxutils.py", line 355, in prepare_input_source
    if source.getCharacterStream() is None and source.getByteStream() is None:
AttributeError: 'PosixPath' object has no attribute 'getCharacterStream'

----------
components: Library (Lib), XML
messages: 303490
nosy: craigh
priority: normal
severity: normal
status: open
title: xml.sax.parse won't accept path objects
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31658>
_______________________________________

From report at bugs.python.org  Sun Oct  1 16:55:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Oct 2017 20:55:11 +0000
Subject: [issue31658] xml.sax.parse won't accept path objects
In-Reply-To: <1506891071.57.0.213398074469.issue31658@psf.upfronthosting.co.za>
Message-ID: <1506891311.01.0.213398074469.issue31658@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31658>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:01:30 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 21:01:30 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <CAKOZuesfNpP-U4-61yxGfHPgROZZXG-FBiFWf=OY0Cxqid+6Lw@mail.gmail.com>
Message-ID: <d27f1fec-9395-9917-2fb0-bbe63fb16edb@free.fr>


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

Le 01/10/2017 ? 21:51, Daniel Colascione a ?crit?:
> 
>> That does sound specialized to me :-) Can you give an example of such a
>> C API?
> 
> The Linux futex protocol, as described in man futex(7), comes to mind.
> Maybe you want to manipulate C++ shared_ptr objects --- these objects also
> rely on atomic operations.

That's even more specialized than I expected...

> It's still faster than waiting several milliseconds for the GIL.

Are you talking about https://bugs.python.org/issue31653? If so, it's
just waiting for an appropriate PR to be filed.

> I don't understand the opposition to this feature request. It's a trivial
> amount of code (invoke a compiler intrinsic), makes the API more complete,
> and addresses a real, specific use case as well as some other hypothetical
> use cases.

That's a compiler-dependent compiler intrinsic (or perhaps a whole range
of them, given there are different widths to cater for), an API wrapping
it, plus some documentation and tests, that we have to maintain until
the end of time (at least nominally).

> The standard library already includes a whole web server and HTTP
> client, a diff engine, various database engines, a facility for parsing
> email, an NNTP client, a GUI system, and a facility for "determin[ing] the
> type of sound [a] file".

It was determined at the time that the use cases for these justified the
effort of maintaining them in the stdlib. For a couple of these (such as
"determining the type of a sound file" or even an NNTP client), I expect
the decision would be different nowadays :-)

Perhaps other core developers will disagree with me and agree to include
(i.e. review, maintain) this functionality.  I simply am not convinced
it deserves being included, but that's not a veto.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:13:01 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 01 Oct 2017 21:13:01 +0000
Subject: [issue31656] Bitwise operations for bytes-type
In-Reply-To: <1506870076.79.0.213398074469.issue31656@psf.upfronthosting.co.za>
Message-ID: <1506892381.17.0.213398074469.issue31656@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

There?s already a bug open for this: Issue 19251. Only equal-length strings should be supported.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31656>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:13:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 21:13:45 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506892425.52.0.213398074469.issue31622@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Currently, Python exposes "thread identifiers" as unsigned long values across multiple modules:

It happened not so long ago. In 3.6 and earlier "thread identifiers" are signed integers. See issue6532, it was massive change. This issue was deferred for long time due to the afraid of breaking the word. And it still was not tested with third-party code.

>> What happens for code that uses e.g. "%x" to format thread ids?
>It's okay for the opaque object to have a int() conversion.

What happens for C code that uses "%lu" to format thread ids?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:17:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Oct 2017 21:17:47 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <1506822647.49.0.213398074469.issue31654@psf.upfronthosting.co.za>
Message-ID: <1506892667.72.0.213398074469.issue31654@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not clear to me what API is needed, but I agree with Antoine that ctypes doesn't look the appropriate place for it. Maybe in multiprocessing or subprocess, or in low-level module providing primitives for multiprocessing or subprocess?

----------
nosy: +serhiy.storchaka
versions: +Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:33:20 2017
From: report at bugs.python.org (Daniel Colascione)
Date: Sun, 01 Oct 2017 21:33:20 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <d27f1fec-9395-9917-2fb0-bbe63fb16edb@free.fr>
Message-ID: <CAKOZuetSkrGGxrKygUbRbUvtyrvM=5Bqyi89cZJqyX-s7k9BRQ@mail.gmail.com>


Daniel Colascione <dancol at google.com> added the comment:

On Sun, Oct 1, 2017 at 2:01 PM, Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le 01/10/2017 ? 21:51, Daniel Colascione a ?crit :
> >
> >> That does sound specialized to me :-) Can you give an example of such a
> >> C API?
> >
> > The Linux futex protocol, as described in man futex(7), comes to mind.
> > Maybe you want to manipulate C++ shared_ptr objects --- these objects
> also
> > rely on atomic operations.
>
> That's even more specialized than I expected...
>

Huh? Both are very generic.

>
> > It's still faster than waiting several milliseconds for the GIL.
>
> Are you talking about https://bugs.python.org/issue31653? If so, it's
> just waiting for an appropriate PR to be filed.
>

This is a separate issue. That's about thrashing around less when we take a
lock. This issue is about process A not having to wait on process B to
schedule a thread in order to perform a simple operation on memory that
both processes own.

>
> > I don't understand the opposition to this feature request. It's a trivial
> > amount of code (invoke a compiler intrinsic), makes the API more
> complete,
> > and addresses a real, specific use case as well as some other
> hypothetical
> > use cases.
>
> That's a compiler-dependent compiler intrinsic (or perhaps a whole range
> of them, given there are different widths to cater for), an API wrapping
> it, plus some documentation and tests, that we have to maintain until
> the end of time (at least nominally).
>

It's trivial and easy to support conditionally. SCM_RIGHTS is "specialized"
and not supported on all systems, yet it's in stdlib.

>
> > The standard library already includes a whole web server and HTTP
> > client, a diff engine, various database engines, a facility for parsing
> > email, an NNTP client, a GUI system, and a facility for "determin[ing]
> the
> > type of sound [a] file".
>
> It was determined at the time that the use cases for these justified the
> effort of maintaining them in the stdlib. For a couple of these (such as
> "determining the type of a sound file" or even an NNTP client), I expect
> the decision would be different nowadays :-)
>
> Perhaps other core developers will disagree with me and agree to include
> (i.e. review, maintain) this functionality.  I simply am not convinced
> it deserves being included, but that's not a veto.
>

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31654>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:35:18 2017
From: report at bugs.python.org (Daniel Colascione)
Date: Sun, 01 Oct 2017 21:35:18 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <d27f1fec-9395-9917-2fb0-bbe63fb16edb@free.fr>
Message-ID: <CAKOZuetnjcnShhbe5AzxBw0MYdb0DdXE0fZ_Y5vyRRQ+UuqkLQ@mail.gmail.com>


Daniel Colascione <dancol at google.com> added the comment:

On Sun, Oct 1, 2017 at 2:01 PM, Antoine Pitrou <report at bugs.python.org>
wrote:

> Perhaps other core developers will disagree with me and agree to include
> (i.e. review, maintain) this functionality.  I simply am not convinced
> it deserves being included, but that's not a veto.

ctypes is a library for operating on native memory and working with native
functions. Performing atomic operations on memory is definitely within its
scope. Why does ctypes include memmove? Why memmove and not
compare-and-exchange? What evidence, if any, would convince you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:47:59 2017
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Oct 2017 21:47:59 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506894479.04.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Ah!  So it looks like OpenBSD took its math functions from Sun's fdlibm.  I believe wxMaxima does too.  That would certainly explain why they give the same answer ;-)

So who's right?  Using "bigfloats" in wxMaxima and feeding its bigfloat tan() the exact decimal value corresponding to the binary double denoted by 1.5707963267948961, it reproduces the result the test is expecting.  Ditto by writing my own tan function, using `decimal` with 50 digits, using the straightforward series expansions for sin and cos, and then dividing to get tan (slow, but without any attempt at "cleverness" it's easy to trust it).

So if fdlibm's author were still active, I'm sure he'd consider this to be a bug - it _intended_ to have < 1 ulp error in almost all cases.

It's not argument reduction that's hurting it.  fdlibm stores pi/2 to waaaay more bits than are needed to get the right answer via -1/tan(x - pi/2).  

Regardless, there's nothing Python can do about it short of changing the test.  As the Python results I pasted before show, the OpenBSD answer _is_ correct for some (non-representable in double precision) input value within 1 ulp of the actual input value.  So it's a very demanding test to get right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:52:17 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 01 Oct 2017 21:52:17 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1506894737.66.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Problem happen during pdflatex, I tried a local build and got: 

! Package hyperref Error: Wrong DVI mode driver option `dvipdfmx',
(hyperref)                because pdfTeX or LuaTeX is running in PDF mode.

See the hyperref package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.4362 \ProcessKeyvalOptions{Hyp}
                                 
? 
! Emergency stop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:53:21 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Oct 2017 21:53:21 +0000
Subject: [issue31654] ctypes should support atomic operations
In-Reply-To: <CAKOZuetSkrGGxrKygUbRbUvtyrvM=5Bqyi89cZJqyX-s7k9BRQ@mail.gmail.com>
Message-ID: <6b8ba39c-5479-4748-6e9e-88b80095590e@free.fr>


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

Le 01/10/2017 ? 23:33, Daniel Colascione a ?crit?:
> 
> Huh? Both are very generic.

"Specialized" as in "I didn't expect anyone would want to do such a
thing in pure Python".

> SCM_RIGHTS is "specialized"
> and not supported on all systems, yet it's in stdlib.

Because passing fds between processes was considered useful enough (it's
actually used by multiprocessing itself, for example to implement the
forkserver model).

And regardless, trying to point to other (more or less exotic) features
of the stdlib is not a convincing argument to add a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________

From report at bugs.python.org  Sun Oct  1 17:54:28 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 01 Oct 2017 21:54:28 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1506894868.15.0.213398074469.issue31589@psf.upfronthosting.co.za>


Change by Julien Palard <julien+python at palard.fr>:


----------
nosy: +linkid

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Oct  1 18:01:07 2017
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 01 Oct 2017 22:01:07 +0000
Subject: [issue27494] 2to3 parser failure caused by a comma after a generator
 expression
In-Reply-To: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za>
Message-ID: <1506895267.4.0.213398074469.issue27494@psf.upfronthosting.co.za>


Jakub Stasiak <jakub+python.org at stasiak.at> added the comment:

By "forbid" do you mean "forbid in Python" (as in change Python syntax)? I like the idea but that seems like a more serious change and 2to3 arguably needs to handle code targeting older Python versions anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27494>
_______________________________________

From report at bugs.python.org  Sun Oct  1 18:36:48 2017
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 01 Oct 2017 22:36:48 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1506897408.48.0.213398074469.issue31589@psf.upfronthosting.co.za>


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

FWIW most of the errors I met while trying to build the pdfs of the main docs were caused by the presence of non-latin1 characters.  French should be limited to the latin1 range and the error you pasted doesn't seem to be related, however that might explain while the Japanese docs are also missing (unless this issue got fixed in the meanwhile -- I haven't built the pdfs in a while).

----------
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Oct  1 19:11:49 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 01 Oct 2017 23:11:49 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1506899509.15.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

After an upgrade of my venv, the error is now:

Latexmk: applying rule 'pdflatex'...
Rule 'pdflatex': File changes, etc:
   Changed files, or newly in use since previous run(s):
      'faq.aux'
      'faq.out'
      'faq.toc'
Latexmk: Maximum runs of pdflatex reached without getting stable files
Latexmk: All targets (faq.pdf) are up-to-date
Latexmk: Did not finish processing file 'faq.tex':
   'pdflatex' needed too many passes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Oct  1 19:32:44 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 01 Oct 2017 23:32:44 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1506900764.98.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

One difference I see in the logs of sucessfully building the faq.tex and failing to build it is:

   Package hyperref Warning: Token not allowed in a PDF string (Unicode):

Looks like if I remove all non-ascii characters from titles, it builds again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Oct  1 20:32:54 2017
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 02 Oct 2017 00:32:54 +0000
Subject: [issue21983] segfault in ctypes.cast
In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>
Message-ID: <1506904374.83.0.213398074469.issue21983@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21983>
_______________________________________

From report at bugs.python.org  Sun Oct  1 20:37:19 2017
From: report at bugs.python.org (Rufus V. Smith)
Date: Mon, 02 Oct 2017 00:37:19 +0000
Subject: [issue27484] Some Examples in Format String Syntax are incorrect or
 poorly worded
In-Reply-To: <1468260642.45.0.0477478332119.issue27484@psf.upfronthosting.co.za>
Message-ID: <083A0A3B-598B-4399-A246-DFC4B7D31F36@gmail.com>


Rufus V. Smith <rufusvsmith at gmail.com> added the comment:

I happened to run across this in my old email inbox.

It's embarrassing to realize how wrong I was in submitting the report.

Reading it with fresh eyes, your original makes sense.

I don't know what I was thinking.

> On Jul 11, 2016, at 2:10 PM, Raymond Hettinger <report at bugs.python.org> wrote:
> 
> 
> Raymond Hettinger added the comment:
> 
> I think all of these read fine as-is though I would change "argument first" to  "first argument" or just "argument".   Adding the word "positional" is a distractor from what the comments are trying to communicate.
> 
> The version numbering is normally done with a directive and outside of the examples.
> 
> ----------
> nosy: +rhettinger
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27484>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27484>
_______________________________________

From report at bugs.python.org  Sun Oct  1 20:47:35 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 02 Oct 2017 00:47:35 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
Message-ID: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>


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

Current DER_cert_to_PEM_cert() uses textwrap like this:

    def DER_cert_to_PEM_cert(der_cert_bytes):
        """Takes a certificate in binary DER format and returns the
        PEM version of it as a string."""

        f = str(base64.standard_b64encode(der_cert_bytes), 'ASCII', 'strict')
        return (PEM_HEADER + '\n' +
                textwrap.fill(f, 64) + '\n' +
                PEM_FOOTER + '\n')

But textwrap is designed to break lines at word boundary.
So textwrap.fill for base64 text may be slow.

And `import textwrap` is little slow too.

We can use simple slicing instead of textwrap.

----------
messages: 303505
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: ssl module should not use textwrap for wrapping PEM format.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Sun Oct  1 20:47:49 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 02 Oct 2017 00:47:49 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>
Message-ID: <1506905269.73.0.213398074469.issue31659@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
components: +Library (Lib)
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Sun Oct  1 20:50:39 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 02 Oct 2017 00:50:39 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>
Message-ID: <1506905439.44.0.213398074469.issue31659@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +3829
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Sun Oct  1 20:53:20 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 02 Oct 2017 00:53:20 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>
Message-ID: <1506905600.47.0.213398074469.issue31659@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

For the record, this is part of `import requests`.
`import ssl` took 11 ms and `textwrap` weights 2.4 ms of it.

                    - ipaddress 2048 us (self 2048 us)
                    - textwrap 2402 us (self 2402 us)
                    - _ssl 2744 us (self 2744 us)
                        - _struct 232 us (self 232 us)
                      - struct 411 us (self 180 us)
                      - binascii 272 us (self 272 us)
                    - base64 997 us (self 315 us)
                  - ssl 11158 us (self 2969 us)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Sun Oct  1 23:12:27 2017
From: report at bugs.python.org (Stephen Moore)
Date: Mon, 02 Oct 2017 03:12:27 +0000
Subject: [issue31660] sys.executable different in os.execv'd python3.6
 virtualenv session in python2 vs python3
Message-ID: <1506913947.94.0.213398074469.issue31660@psf.upfronthosting.co.za>


New submission from Stephen Moore <delfick755 at gmail.com>:

Hi,

I've come across a problem whereby if you do an os.execv to a python3.6 virtualenv python inside python2.7 vs python3.6 then the resulting python session has a different sys.executable.

Where if you os.execv from python2.7 the sys.executable is equal to the virtualenv python

Whereas from python3.6 the resulting python session has a sys.executable of the system python.

An example of this in play can be found at https://gist.github.com/delfick/d750dc83e3b28e90cef8e2bfbd5b175a

Note that I don't see the problem if the virtualenv is based on python2.7 (https://gist.github.com/delfick/f1ad6872e2614189a7d98f2583ffc564)

----------
components: macOS
messages: 303507
nosy: Stephen Moore, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: sys.executable different in os.execv'd python3.6 virtualenv session in python2 vs python3
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31660>
_______________________________________

From report at bugs.python.org  Mon Oct  2 02:14:07 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 06:14:07 +0000
Subject: [issue31661] Issues with request rate in robotparser
Message-ID: <1506924847.15.0.213398074469.issue31661@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are issues in implementing support of request rate in robotparser.

    req_rate = collections.namedtuple('req_rate',
                                      'requests seconds')
    entry.req_rate = req_rate
    entry.req_rate.requests = int(numbers[0])
    entry.req_rate.seconds = int(numbers[1])

First, a new namedtuple type is created for every entry. This is slow even with recent namedtuple optimizations, and is much slower in 3.6. This wastes a memory, since new type is created for every entry. This is definitely wrong, since req_rate is set to a namedtuple type instead of namedtuple instance. And there is a question why a namedtuple is used here at all. Other classes in this module are not namedtuples.

----------
components: Library (Lib)
messages: 303508
nosy: XapaJIaMnu, berker.peksag, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Issues with request rate in robotparser
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31661>
_______________________________________

From report at bugs.python.org  Mon Oct  2 02:26:17 2017
From: report at bugs.python.org (Nikolay Bogoychev)
Date: Mon, 02 Oct 2017 06:26:17 +0000
Subject: [issue31661] Issues with request rate in robotparser
In-Reply-To: <1506924847.15.0.213398074469.issue31661@psf.upfronthosting.co.za>
Message-ID: <1506925577.55.0.213398074469.issue31661@psf.upfronthosting.co.za>


Nikolay Bogoychev <nheart at gmail.com> added the comment:

Hey Serhiy,

The use of namedtuple was requested specifically at a review, I didn't implement it like this initially: https://bugs.python.org/review/16099/#ps6205

I wasn't aware of the performance implications. Could you please explain to me the type vs instance in terms of performance (or point me to a resource, a quick googling didn't yield anything? How was I supposed to have coded it properly?

Cheers,

Nick

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31661>
_______________________________________

From report at bugs.python.org  Mon Oct  2 03:02:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 07:02:08 +0000
Subject: [issue31661] Issues with request rate in robotparser
In-Reply-To: <1506924847.15.0.213398074469.issue31661@psf.upfronthosting.co.za>
Message-ID: <1506927728.14.0.213398074469.issue31661@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For the performance of namedtuple type creation see issue28638 and https://mail.python.org/pipermail/python-dev/2017-July/148592.html. For difference between types and instance see https://docs.python.org/3/tutorial/classes.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31661>
_______________________________________

From report at bugs.python.org  Mon Oct  2 03:24:52 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 Oct 2017 07:24:52 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1506929092.85.0.213398074469.issue31622@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that it would be entirely possible to leave the Python level thread IDs alone, but change the way they were used internally to keep the thread ID distinct from the operating system level thread handle.

That would limit the adjustment to signal.pthread_kill() and other APIs that wanted to resolve the integer ID back to an OS level handle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Mon Oct  2 03:33:47 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 02 Oct 2017 07:33:47 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>
Message-ID: <1506929627.23.0.213398074469.issue31659@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset b75a228af8c0553aef44e4e03763af90fbc8737f by INADA Naoki in branch 'master':
bpo-31659: Use simple slicing to format PEM cert (GH-3849)
https://github.com/python/cpython/commit/b75a228af8c0553aef44e4e03763af90fbc8737f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Mon Oct  2 03:34:03 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 02 Oct 2017 07:34:03 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>
Message-ID: <1506929643.12.0.213398074469.issue31659@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Mon Oct  2 04:12:16 2017
From: report at bugs.python.org (Anselm Kruis)
Date: Mon, 02 Oct 2017 08:12:16 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
Message-ID: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>


New submission from Anselm Kruis <a.kruis at science-computing.de>:

There are 3 trivial typos in Tools/msi/uploadrelease.bat: "godo" instead of "goto" in lines 25 to 28.

----------
components: Build
messages: 303513
nosy: anselm.kruis, steve.dower
priority: normal
severity: normal
status: open
title: trivial typos in Tools/msi/uploadrelease.bat
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 04:29:33 2017
From: report at bugs.python.org (Anselm Kruis)
Date: Mon, 02 Oct 2017 08:29:33 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506932973.84.0.213398074469.issue31662@psf.upfronthosting.co.za>


Change by Anselm Kruis <a.kruis at science-computing.de>:


----------
keywords: +patch
pull_requests: +3830
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:20:56 2017
From: report at bugs.python.org (Jan-Philip Gehrcke)
Date: Mon, 02 Oct 2017 09:20:56 +0000
Subject: [issue16487] Allow ssl certificates to be specified from memory
 rather than files.
In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za>
Message-ID: <1506936056.89.0.213398074469.issue16487@psf.upfronthosting.co.za>


Jan-Philip Gehrcke <jgehrcke at gmail.com> added the comment:

Hey Antoine, Christian, Senthil!

I have invested quite a bit more time to double-check my responses to the questions asked so far, clarified where appropriate, and updated the pull request on GitHub after manually resolving the merge conflicts that accumulated over time.

I would very much appreciate to get another round of feedback. Can we somehow expedite this? I am available for pushing this further, so that maybe we can still land this in 3.7 after we missed 3.6 last year.

Based on the diff this change _appears_ to be risky but I would like to stress again that I approached this issue pretty conservatively. I tried to make this a conceptually backwards-compatible change by keeping the old code path intact (the old tests pass, too, but this is not the best criterion here).

Cheers and thanks!

Jan-Philip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16487>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:24:09 2017
From: report at bugs.python.org (Basanna Badami)
Date: Mon, 02 Oct 2017 09:24:09 +0000
Subject: [issue31663] pyautogui.typewrite() method doesn't work as expected.
Message-ID: <1506936249.54.0.213398074469.issue31663@psf.upfronthosting.co.za>


New submission from Basanna Badami <talk2basanna at gmail.com>:

Tried to run pyautogui.typewrite('Hello World') On IDLE terminal to type 'Hello World' string to an open notepad(say). As, i've interchanged my mouse click options(on windows OS), instead of 'Hello World' string being print to to the open notepad, i could see a right click on it.

The method pyautogui.typewrite() doesn't function as per mouse options settings on my machine.

----------
components: Windows
messages: 303515
nosy: basanna007, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pyautogui.typewrite() method doesn't work as expected.
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31663>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:24:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 09:24:48 +0000
Subject: [issue31664] Add support of new crypt methods
Message-ID: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Proposed PR adds support of three new methods in the crypt module.

1. Blowfish. It is considered as strong as SSH512 for crypt() purpose. There are several variants of this method: '2', '2a', '2b' and '2y'. '2y' looks the same as '2b', other variants have different flaws. All four are supported on FreeBSD. '2b' is the only method available on OpenBSD, hence this change also fixes crypt on OpenBSD (see issue25287). Blowfish is not supported in glibc, but it is added in some Linux distributions (not in Ubuntu). The most strong of the available variants is chosen.

2. Extended DES. In contrary to traditional default algorithm it uses salt longer than 2 characters. It is supported on FreeBSD.

3. NT-Hash. It doesn't use salt and is compatible with Microsoft's NT scheme. It is supported on FreeBSD.

mksalt() now takes the log_rounds argument for Blowfish. I'm not sure this is the best solution. And what should be a default value?

----------
messages: 303516
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support of new crypt methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:31:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:31:29 +0000
Subject: [issue29041] Reference leaks on Windows
In-Reply-To: <1482359321.76.0.526806281889.issue29041@psf.upfronthosting.co.za>
Message-ID: <1506936689.21.0.213398074469.issue29041@psf.upfronthosting.co.za>


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

> Victor has cleaned these up, and we now have a buildbot running refleak checks on Windows every day (as long as it's not hung :)

\o/ Hopefully I was alone ;-) https://haypo.github.io/contrib-cpython-2017q2-part2.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29041>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:37:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:37:51 +0000
Subject: [issue30576] http.server should support HTTP compression (gzip)
In-Reply-To: <1496691724.59.0.955308322691.issue30576@psf.upfronthosting.co.za>
Message-ID: <1506937071.04.0.213398074469.issue30576@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30576>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:39:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:39:58 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506937198.18.0.213398074469.issue31158@psf.upfronthosting.co.za>


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


New changeset e6f62f69f07892b993910ff03c9db3ffa5cb9ca5 by Victor Stinner (Cornelius Diekmann) in branch 'master':
bpo-31158: Fix nondeterministic read in test_pty (#3808)
https://github.com/python/cpython/commit/e6f62f69f07892b993910ff03c9db3ffa5cb9ca5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:40:50 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Oct 2017 09:40:50 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506937250.14.0.213398074469.issue31158@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3832

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:47:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:47:28 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506937648.91.0.213398074469.issue31158@psf.upfronthosting.co.za>


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


----------
pull_requests: +3833

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:48:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:48:52 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506937732.88.0.213398074469.issue31158@psf.upfronthosting.co.za>


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

> I prefer Cornelius?s current proposal (rev 4f8137b)

Ok, fine. I merged his PR 3852. I created backports to 2.7 and 3.6.

----------
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:50:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 09:50:17 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1506937817.96.0.213398074469.issue31664@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3834
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:52:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:52:51 +0000
Subject: [issue28027] Remove Lib/plat-*/* files
In-Reply-To: <1473359899.1.0.11929160412.issue28027@psf.upfronthosting.co.za>
Message-ID: <1506937971.35.0.213398074469.issue28027@psf.upfronthosting.co.za>


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

Thank you Zachary for this removal ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28027>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:53:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 09:53:47 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1506938027.64.0.213398074469.issue31664@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)
nosy: +christian.heimes, dstufft, gregory.p.smith, jafo
type:  -> enhancement
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:56:16 2017
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Oct 2017 09:56:16 +0000
Subject: [issue31659] ssl module should not use textwrap for wrapping PEM
 format.
In-Reply-To: <1506905254.99.0.213398074469.issue31659@psf.upfronthosting.co.za>
Message-ID: <1506938176.35.0.213398074469.issue31659@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31659>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:57:13 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:57:13 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1506938233.03.0.213398074469.issue31655@psf.upfronthosting.co.za>


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

Please reject non-string keys. I don't see any good reason to use non-string, and it's painful to support such CPython implementation details in other Python implementations.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:57:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:57:58 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506938278.87.0.213398074469.issue31158@psf.upfronthosting.co.za>


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


New changeset 66fb5ef3bb9e36187a0e5052dfd99899447df671 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31158: Fix nondeterministic read in test_pty (GH-3808) (GH-3852)
https://github.com/python/cpython/commit/66fb5ef3bb9e36187a0e5052dfd99899447df671


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:58:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:58:11 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506938291.21.0.213398074469.issue31158@psf.upfronthosting.co.za>


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


New changeset 20cbc1d29facead32c2da06c81a09af0e057015c by Victor Stinner in branch '2.7':
bpo-31158: Fix nondeterministic read in test_pty (#3808) (#3853)
https://github.com/python/cpython/commit/20cbc1d29facead32c2da06c81a09af0e057015c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:58:31 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:58:31 +0000
Subject: [issue16487] Allow ssl certificates to be specified from memory
 rather than files.
In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za>
Message-ID: <1506938311.13.0.213398074469.issue16487@psf.upfronthosting.co.za>


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


----------
components:  -Library (Lib)
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16487>
_______________________________________

From report at bugs.python.org  Mon Oct  2 05:59:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 09:59:15 +0000
Subject: [issue31158] test_pty: test_basic() fails randomly on Travis CI
In-Reply-To: <1502275933.96.0.349321322315.issue31158@psf.upfronthosting.co.za>
Message-ID: <1506938355.5.0.213398074469.issue31158@psf.upfronthosting.co.za>


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

Thanks Cornelius Diekmann for your fix ;-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31158>
_______________________________________

From report at bugs.python.org  Mon Oct  2 06:02:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 10:02:07 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506938527.74.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

> It's expected if uuid_generate_time_safe() isn't available on your platform.  But test_uuid still passes?

I would prefer to avoid compilation errors on a popular platforms like macOS. Would it possible to check if uuid_generate_time_safe() is available, maybe in configure? Or we can "simply" skip _uuid compilation on macOS?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 06:17:25 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Oct 2017 10:17:25 +0000
Subject: [issue31661] Issues with request rate in robotparser
In-Reply-To: <1506924847.15.0.213398074469.issue31661@psf.upfronthosting.co.za>
Message-ID: <1506939445.45.0.213398074469.issue31661@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report. Your analysis is correct and this is a duplicate of issue 31325. I'll take care of the PR 3259.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> req_rate is a namedtuple type rather than instance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31661>
_______________________________________

From report at bugs.python.org  Mon Oct  2 06:17:40 2017
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Oct 2017 10:17:40 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1506939460.58.0.213398074469.issue31664@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

-1 on DES and NT Hash

These are very old, very bad algorithms and should no longer be used. We are in the 21th century.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Mon Oct  2 06:27:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 10:27:28 +0000
Subject: [issue31325] req_rate is a namedtuple type rather than instance
In-Reply-To: <1504278922.84.0.0240979311873.issue31325@psf.upfronthosting.co.za>
Message-ID: <1506940048.61.0.213398074469.issue31325@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31325>
_______________________________________

From report at bugs.python.org  Mon Oct  2 06:30:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 10:30:03 +0000
Subject: [issue31325] req_rate is a namedtuple type rather than instance
In-Reply-To: <1504278922.84.0.0240979311873.issue31325@psf.upfronthosting.co.za>
Message-ID: <1506940203.57.0.213398074469.issue31325@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is a reason of making req_rate a named tuple?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31325>
_______________________________________

From report at bugs.python.org  Mon Oct  2 06:32:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 10:32:24 +0000
Subject: [issue31661] Issues with request rate in robotparser
In-Reply-To: <1506924847.15.0.213398074469.issue31661@psf.upfronthosting.co.za>
Message-ID: <1506940344.62.0.213398074469.issue31661@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oh, I missed this. My report is based on the same comment on news.ycombinator.com.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31661>
_______________________________________

From report at bugs.python.org  Mon Oct  2 07:35:04 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Oct 2017 11:35:04 +0000
Subject: [issue31660] sys.executable different in os.execv'd python3.6
 virtualenv session in python2 vs python3
In-Reply-To: <1506913947.94.0.213398074469.issue31660@psf.upfronthosting.co.za>
Message-ID: <1506944104.45.0.213398074469.issue31660@psf.upfronthosting.co.za>


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

virtualenv is not part of the standard library.  What happens if you use venv instead?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31660>
_______________________________________

From report at bugs.python.org  Mon Oct  2 08:24:19 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 12:24:19 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506947059.55.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

> Would it possible to check if uuid_generate_time_safe() is available, maybe in configure?

That's probably possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 08:31:15 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 12:31:15 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506947475.44.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

Though I don't know how to reuse the find_file() logic in configure...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 09:15:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 13:15:24 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506950123.99.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

> Though I don't know how to reuse the find_file() logic in configure...

Maybe we could use pkg-config instead?

haypo at selma$ pkg-config uuid --cflags
-I/usr/include/uuid 
haypo at selma$ pkg-config uuid --libs
-luuid

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 09:39:49 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 02 Oct 2017 13:39:49 +0000
Subject: [issue31660] sys.executable different in os.execv'd python3.6
 virtualenv session in python2 vs python3
In-Reply-To: <1506913947.94.0.213398074469.issue31660@psf.upfronthosting.co.za>
Message-ID: <1506951589.07.0.213398074469.issue31660@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31660>
_______________________________________

From report at bugs.python.org  Mon Oct  2 09:43:28 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 13:43:28 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506951808.11.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

pkg-config is a Linux-ism.  But Linux already works fine...

$ uname 
Darwin
$ pkg-config
-bash: pkg-config: command not found

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:04:22 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 14:04:22 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506953062.71.0.213398074469.issue11063@psf.upfronthosting.co.za>


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


----------
pull_requests: +3835
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:33:40 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 14:33:40 +0000
Subject: [issue31510] test_many_processes() of test_multiprocessing_spawn
 failed on x86-64 Sierra 3.x
In-Reply-To: <1505751572.13.0.570284930539.issue31510@psf.upfronthosting.co.za>
Message-ID: <1506954820.24.0.213398074469.issue31510@psf.upfronthosting.co.za>


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

> It looks like a weak synchronization.

It is.  I don't remember exactly why I had to add this, I can't reproduce any issue without it anymore...

> the signal is sent before Python registered signal handlers?

Python signal handlers are not relevant here, we're sending SIGTERM which kills the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31510>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:38:42 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 14:38:42 +0000
Subject: [issue31510] test_many_processes() of test_multiprocessing_spawn
 failed on x86-64 Sierra 3.x
In-Reply-To: <1505751572.13.0.570284930539.issue31510@psf.upfronthosting.co.za>
Message-ID: <1506955122.36.0.213398074469.issue31510@psf.upfronthosting.co.za>


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

It seems other people have similar issues:
https://github.com/libuv/libuv/issues/1226

Perhaps we need to relax the test on OSX :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31510>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:42:17 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 14:42:17 +0000
Subject: [issue31516] current_thread() becomes "dummy" thread during shutdown
In-Reply-To: <1505820834.6.0.00526419251789.issue31516@psf.upfronthosting.co.za>
Message-ID: <1506955337.7.0.213398074469.issue31516@psf.upfronthosting.co.za>


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


New changeset 1023dbbcb7f05e76053486ae7ef7f73b4cdc5398 by Antoine Pitrou in branch 'master':
bpo-31516: current_thread() should not return a dummy thread at shutdown (#3673)
https://github.com/python/cpython/commit/1023dbbcb7f05e76053486ae7ef7f73b4cdc5398


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31516>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:42:32 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Oct 2017 14:42:32 +0000
Subject: [issue31516] current_thread() becomes "dummy" thread during shutdown
In-Reply-To: <1505820834.6.0.00526419251789.issue31516@psf.upfronthosting.co.za>
Message-ID: <1506955352.68.0.213398074469.issue31516@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3836

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31516>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:48:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 14:48:14 +0000
Subject: [issue31510] test_many_processes() of test_multiprocessing_spawn
 failed on x86-64 Sierra 3.x
In-Reply-To: <1505751572.13.0.570284930539.issue31510@psf.upfronthosting.co.za>
Message-ID: <1506955694.64.0.213398074469.issue31510@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3837
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31510>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:48:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 14:48:59 +0000
Subject: [issue31510] test_many_processes() of test_multiprocessing_spawn
 failed on x86-64 Sierra 3.x
In-Reply-To: <1505751572.13.0.570284930539.issue31510@psf.upfronthosting.co.za>
Message-ID: <1506955739.73.0.213398074469.issue31510@psf.upfronthosting.co.za>


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

Antoine: "It seems other people have similar issues: https://github.com/libuv/libuv/issues/1226 Perhaps we need to relax the test on OSX :-/"

Oh thanks for the confirmation. I proposed a patch to accept -SIGKILL on macOS: PR 3857.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31510>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:49:48 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 14:49:48 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506955788.67.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

I proposed PR 3855 to add macOS support to _uuid (and fix the compilation error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 10:58:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 14:58:02 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506956282.95.0.213398074469.issue11063@psf.upfronthosting.co.za>


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


New changeset 4337a0d9955f0855ba38ef30feec3858d304abf0 by Victor Stinner in branch 'master':
bpo-11063: Fix _uuid module on macOS (#3855)
https://github.com/python/cpython/commit/4337a0d9955f0855ba38ef30feec3858d304abf0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:09:14 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 02 Oct 2017 15:09:14 +0000
Subject: [issue29832] Don't refer to getsockaddrarg in error messages
In-Reply-To: <1489732997.44.0.201686346308.issue29832@psf.upfronthosting.co.za>
Message-ID: <1506956954.28.0.213398074469.issue29832@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Should i remove the code that i wasn't able to test from the PR, and
leave such changes to someone that is able to test it?

(of course, if there is some way i can do it using a VM, please point
that out, and i would try to set up this VM.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29832>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:20:04 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 15:20:04 +0000
Subject: [issue31516] current_thread() becomes "dummy" thread during shutdown
In-Reply-To: <1505820834.6.0.00526419251789.issue31516@psf.upfronthosting.co.za>
Message-ID: <1506957604.43.0.213398074469.issue31516@psf.upfronthosting.co.za>


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


New changeset ac6245a31f9a757db0520722c592cb7fdcb55eb0 by Antoine Pitrou (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31516: current_thread() should not return a dummy thread at shutdown (GH-3673) (#3856)
https://github.com/python/cpython/commit/ac6245a31f9a757db0520722c592cb7fdcb55eb0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31516>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:20:39 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Oct 2017 15:20:39 +0000
Subject: [issue31516] current_thread() becomes "dummy" thread during shutdown
In-Reply-To: <1505820834.6.0.00526419251789.issue31516@psf.upfronthosting.co.za>
Message-ID: <1506957639.92.0.213398074469.issue31516@psf.upfronthosting.co.za>


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

I have now pushed the fix to master and 3.6.  Hopefully this won't break anyone's code...

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31516>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:27:37 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 15:27:37 +0000
Subject: [issue31510] test_many_processes() of test_multiprocessing_spawn
 failed on x86-64 Sierra 3.x
In-Reply-To: <1505751572.13.0.570284930539.issue31510@psf.upfronthosting.co.za>
Message-ID: <1506958057.48.0.213398074469.issue31510@psf.upfronthosting.co.za>


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


New changeset e6cfdefa0c2f5bda177e49b228c2c7528f7c239c by Victor Stinner in branch 'master':
bpo-31510: Fix multiprocessing test_many_processes() on macOS (#3857)
https://github.com/python/cpython/commit/e6cfdefa0c2f5bda177e49b228c2c7528f7c239c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31510>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:38:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Oct 2017 15:38:08 +0000
Subject: [issue31510] test_many_processes() of test_multiprocessing_spawn
 failed on x86-64 Sierra 3.x
In-Reply-To: <1505751572.13.0.570284930539.issue31510@psf.upfronthosting.co.za>
Message-ID: <1506958688.5.0.213398074469.issue31510@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31510>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:42:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 15:42:19 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1506958939.06.0.213398074469.issue31664@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur. Initially I implemented all three methods, then removed they except Blowfish, and then re-added they back just for showing they to security experts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:53:59 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 15:53:59 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506959639.6.0.213398074469.issue31662@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset efb560eee28b6b2418e1231573ca62574d6dc07b by Steve Dower (Anselm Kruis) in branch 'master':
bpo-31662: Fix typos in uploadrelease.bat script
https://github.com/python/cpython/commit/efb560eee28b6b2418e1231573ca62574d6dc07b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:54:23 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 15:54:23 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506959663.57.0.213398074469.issue31662@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Thanks. It is indeed trivial, so I'll merge and backport it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:54:25 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Oct 2017 15:54:25 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506959665.67.0.213398074469.issue31662@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3838

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:54:51 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 15:54:51 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506959691.26.0.213398074469.issue31662@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> backport needed
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:55:58 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 15:55:58 +0000
Subject: [issue31663] pyautogui.typewrite() method doesn't work as expected.
In-Reply-To: <1506936249.54.0.213398074469.issue31663@psf.upfronthosting.co.za>
Message-ID: <1506959758.26.0.213398074469.issue31663@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31663>
_______________________________________

From report at bugs.python.org  Mon Oct  2 11:56:09 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 15:56:09 +0000
Subject: [issue31663] pyautogui.typewrite() method doesn't work as expected.
In-Reply-To: <1506936249.54.0.213398074469.issue31663@psf.upfronthosting.co.za>
Message-ID: <1506959769.55.0.213398074469.issue31663@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31663>
_______________________________________

From report at bugs.python.org  Mon Oct  2 12:07:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 16:07:18 +0000
Subject: [issue31271] an assertion failure in io.TextIOWrapper.write
In-Reply-To: <1503597989.21.0.785820469546.issue31271@psf.upfronthosting.co.za>
Message-ID: <1506960438.71.0.213398074469.issue31271@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oren, do you mind to create a backport to 2.7? miss-islington can not handle it.

----------
stage: patch review -> backport needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31271>
_______________________________________

From report at bugs.python.org  Mon Oct  2 12:20:30 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 16:20:30 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506961230.52.0.213398074469.issue31662@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d6201cb0e865dad116ffe46e5ea3d02e8eeb42c1 by Steve Dower (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31662: Fix typos in uploadrelease.bat script (#3858)
https://github.com/python/cpython/commit/d6201cb0e865dad116ffe46e5ea3d02e8eeb42c1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 12:20:42 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Oct 2017 16:20:42 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1506961242.39.0.213398074469.issue31662@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
stage: backport needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Mon Oct  2 12:57:25 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Oct 2017 16:57:25 +0000
Subject: [issue31325] req_rate is a namedtuple type rather than instance
In-Reply-To: <1504278922.84.0.0240979311873.issue31325@psf.upfronthosting.co.za>
Message-ID: <1506963445.28.0.213398074469.issue31325@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> What is a reason of making req_rate a named tuple?

I don't know the original reason but it seems like a normal use of named tuples to make the data more self-describing to help with debugging and also to support field access by name, rr.requests or rr.seconds is clearer than rr[0] or rr[1].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31325>
_______________________________________

From report at bugs.python.org  Mon Oct  2 12:59:18 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Oct 2017 16:59:18 +0000
Subject: [issue31660] sys.executable different in os.execv'd python3.6
 virtualenv session in python2 vs python3
In-Reply-To: <1506913947.94.0.213398074469.issue31660@psf.upfronthosting.co.za>
Message-ID: <1506963557.99.0.213398074469.issue31660@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I suspect what is being seen here is essentially a duplicate of Issue31363. On macOS framework builds, a python launcher executable is used (Mac/Tools/pythonw.c) to exec the real Python interpreter binary and the launcher uses the __PYVENV_LAUNCHER__ environment variable to be able to handle symlinks (work initially implemented in Issue15307).

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31660>
_______________________________________

From report at bugs.python.org  Mon Oct  2 13:12:09 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Oct 2017 17:12:09 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506964329.1.0.213398074469.issue11063@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I agree with Barry's comment on PR 3855: "I'd rather see a configure check for the existence of uuid_generate_time_safe() rather than hard coding it to platforms !APPLE for two reasons. 1) If macOS ever adds this API in some future release, this ifndef will be incorrect, and 2) if some other platform comes along that doesn't have this API, it will still use the incorrect function."  It's exactly for situations like this that autoconf tests exist; we should not be hardwiring assumptions about the lack of particular platform APIs.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 13:12:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 17:12:18 +0000
Subject: [issue31325] req_rate is a namedtuple type rather than instance
In-Reply-To: <1504278922.84.0.0240979311873.issue31325@psf.upfronthosting.co.za>
Message-ID: <1506964338.01.0.213398074469.issue31325@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a normal use of named tuples for adding access by name to tuple results. But req_rate never was a tuple. Nobody used rr[0].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31325>
_______________________________________

From report at bugs.python.org  Mon Oct  2 13:24:43 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 Oct 2017 17:24:43 +0000
Subject: [issue31663] pyautogui.typewrite() method doesn't work as expected.
In-Reply-To: <1506936249.54.0.213398074469.issue31663@psf.upfronthosting.co.za>
Message-ID: <1506965083.61.0.213398074469.issue31663@psf.upfronthosting.co.za>


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

This tracker is for issues about improving future cpython releases on python.org.  Questions about using current python go to other forums, such as python-list.  You can also use python-list via the news.gmane.org newsgroup mirror gmane.comp.python.general.

If you ask your question elsewhere, you must give much more information.  What is pyautogui.typewrite?  It is not part of the Python stdlib.  What does 'interchanged my mouse click options (on windows OS)' mean?  What did you do in IDLE, in some detail.  What did you see and where?

----------
components:  -IDLE, Windows
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31663>
_______________________________________

From report at bugs.python.org  Mon Oct  2 13:41:28 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 02 Oct 2017 17:41:28 +0000
Subject: [issue11063] Rework uuid module: lazy initialization and add a new C
 extension
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1506966088.63.0.213398074469.issue11063@psf.upfronthosting.co.za>


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

I think the configure check should be this (sets HAVE_LIBUUID in pyconfig.h):

diff --git a/configure.ac b/configure.ac
index 41bd9effbf..90d53c1b7d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2657,6 +2657,7 @@ AC_MSG_RESULT($SHLIBS)
 AC_CHECK_LIB(sendfile, sendfile)
 AC_CHECK_LIB(dl, dlopen)       # Dynamic linking for SunOS/Solaris and SYSV
 AC_CHECK_LIB(dld, shl_load)    # Dynamic linking for HP-UX
+AC_CHECK_LIB(uuid, uuid_generate_time_safe)
 
 # only check for sem_init if thread support is requested
 if test "$with_threads" = "yes" -o -z "$with_threads"; then

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:39:23 2017
From: report at bugs.python.org (Tim Peters)
Date: Mon, 02 Oct 2017 18:39:23 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506969563.08.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

If someone opens a bug report with OpenBSD, or just for us to get more info, it could be useful to have a larger universe of troublesome tan inputs to stare at.  So the attached tanny.py supplies them, testing all inputs within 100 ulps of math.pi/2 (or change N=100 to whatever you like).

There are no failures on my 64-bit Win10 3.6.1.

The "correct" answers are computed by using mpmath.tan() set to 200 mantissa bits, then rounding back to 53 bits.  These all match the results from my dirt-dumb decimal tan() rounded back, but it's better to trust a widely-used package.

Of course mpmath needs to be installed ("pip install mpmath" works fine):

    http://mpmath.org/

Nothing else is needed (while mpmath will exploit gmpy if it's installed, by default it sticks to pure Python code).

----------
Added file: https://bugs.python.org/file47183/tanny.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:43:20 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 02 Oct 2017 18:43:20 +0000
Subject: [issue21983] segfault in ctypes.cast
In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>
Message-ID: <1506969800.17.0.213398074469.issue21983@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3839
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21983>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:44:04 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 02 Oct 2017 18:44:04 +0000
Subject: [issue21983] segfault in ctypes.cast
In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>
Message-ID: <1506969844.79.0.213398074469.issue21983@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
versions: +Python 3.7 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21983>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:44:28 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 02 Oct 2017 18:44:28 +0000
Subject: [issue21983] segfault in ctypes.cast
In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za>
Message-ID: <1506969868.68.0.213398074469.issue21983@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21983>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:47:07 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Oct 2017 18:47:07 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1506970027.58.0.213398074469.issue31567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> What does @ mean here? If there's some meaning, the next question is, why doc for staticmethod()
> (and classmethod() in the same page) does not have it?

@ means that the function is meant to be used as a decorator (the markup looks like the actual code).

staticmethod and classmethod are older than the decorator syntax, which is older than the special sphinx markup for decorators (they used to just use the function markup).

For unittest.mock.patch, its result can be used as a decorator or as a context manager, so the current markup (no @) makes sense.

If you want to update staticmethod and classmethod to use the decorator markup, please send a pull request!  (more info in the devguide)

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:50:13 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 02 Oct 2017 18:50:13 +0000
Subject: [issue31271] an assertion failure in io.TextIOWrapper.write
In-Reply-To: <1503597989.21.0.785820469546.issue31271@psf.upfronthosting.co.za>
Message-ID: <1506970213.43.0.213398074469.issue31271@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

sure

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31271>
_______________________________________

From report at bugs.python.org  Mon Oct  2 14:57:53 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 18:57:53 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506970673.86.0.213398074469.issue31630@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: https://bugs.python.org/file47184/tanny-openbsd.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Mon Oct  2 15:06:53 2017
From: report at bugs.python.org (Tim Peters)
Date: Mon, 02 Oct 2017 19:06:53 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506971213.74.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Thanks for tanny-openbsd.txt, Serhiy!  OpenBSD didn't get anywhere close to the best answer on any of those 201 inputs.  I was hoping we could, e.g., test something a little more removed from pi/2 - but even its best cases in this range are hundreds of millions of ulps off :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Mon Oct  2 15:26:06 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 Oct 2017 19:26:06 +0000
Subject: [issue31665] Edit "Setting [windows] environmental variables"
Message-ID: <1506972366.59.0.213398074469.issue31665@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Python Setup and Usage, 3.3.1. Excursus: Setting environment variables
https://docs.python.org/3/using/windows.html#excursus-setting-environment-variables

The word 'excursus' is so rare and archaic that this is my first encounter with it.  Could we drop it?

The last paragraph starts with "To permanently modify the default environment variables, click Start and search for ?edit environment variables?,".  This part is fine on Windows 10 as it brings up "Edit the system environment variables" and "Edit environmental variables for your account".  Both take one to an Environmental variables dialog.  The former requires than one be or become an admin user (via UAC dialog). 

The paragraph continues "or open System properties, Advanced system settings and click the Environment Variables button. In this dialog, you can add or modify User and System variables. To change System variables, you need non-restricted access to your machine (i.e. Administrator rights)."

On Windows 10, at least, this is confusing or wrong.  Control Panel has 'System' linked to the System dialog.  This has 'Advanced systems settings' linked to System Properties, but one only get there by being or becoming (via UAC) an admin user.  This has the  Environmental Properties button mentioned above.  It opens Environmental Variables for the admin user you are or are acting as.  This route cannot change EVs for non-admin users.  I have the impression that this has changed since Win 7.

----------
assignee: docs at python
components: Documentation, Windows
messages: 303560
nosy: docs at python, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Edit "Setting [windows] environmental variables"
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31665>
_______________________________________

From report at bugs.python.org  Mon Oct  2 15:27:06 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Oct 2017 19:27:06 +0000
Subject: [issue31325] req_rate is a namedtuple type rather than instance
In-Reply-To: <1504278922.84.0.0240979311873.issue31325@psf.upfronthosting.co.za>
Message-ID: <1506972426.39.0.213398074469.issue31325@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There is no rule that something had to be a tuple at some point in its history before becoming a named tuple.  This use seems perfectly reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31325>
_______________________________________

From report at bugs.python.org  Mon Oct  2 15:42:56 2017
From: report at bugs.python.org (Scott Tucholka)
Date: Mon, 02 Oct 2017 19:42:56 +0000
Subject: [issue31666] Pandas_datareader Error Message - ModuleNotFoundError:
 No module named 'pandas_datareader' with module in folder
Message-ID: <1506973376.41.0.213398074469.issue31666@psf.upfronthosting.co.za>


Change by Scott Tucholka <s.tucholka at gmail.com>:


----------
components: Library (Lib), Windows
nosy: Scott Tucholka, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Pandas_datareader Error Message - ModuleNotFoundError: No module named 'pandas_datareader' with module in folder
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31666>
_______________________________________

From report at bugs.python.org  Mon Oct  2 15:43:57 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 02 Oct 2017 19:43:57 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1506973437.22.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Problem looks like the utf8x package is not friend with tableofcontent:

- https://tex.stackexchange.com/questions/240801/utf8x-character-fails-in-the-table-of-contents-every-second-time-i-compile
- https://tex.stackexchange.com/questions/164458/pleaseinsertintopreamble-in-toc-and-header

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Mon Oct  2 16:04:55 2017
From: report at bugs.python.org (linkid)
Date: Mon, 02 Oct 2017 20:04:55 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
Message-ID: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>


New submission from linkid <francois.magimel at alumni.enseeiht.fr>:

In gettext.NullTranslations class doc [0], links to gettext and ngettext methods are not consistent.

[0] https://docs.python.org/3/library/gettext.html#the-nulltranslations-class

----------
assignee: docs at python
components: Documentation
messages: 303563
nosy: docs at python, linkid
priority: normal
severity: normal
status: open
title: Wrong links in the gettext.NullTranslations class
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Mon Oct  2 16:17:56 2017
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 02 Oct 2017 20:17:56 +0000
Subject: [issue31665] Edit "Setting [windows] environmental variables"
In-Reply-To: <1506972366.59.0.213398074469.issue31665@psf.upfronthosting.co.za>
Message-ID: <1506975476.04.0.213398074469.issue31665@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

AFAIK, the "Advanced system settings" dialog has always required administrator access. To modify the environment for just the current user, in the control panel there's "User Accounts" => "Change my environment variables".

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31665>
_______________________________________

From report at bugs.python.org  Mon Oct  2 17:07:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 21:07:57 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1506978477.82.0.213398074469.issue31667@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3840
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Mon Oct  2 17:09:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 21:09:31 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1506978571.28.0.213398074469.issue31667@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Good catch linkid! PR 3860 fixes these and several other gettext related links.

----------
nosy: +serhiy.storchaka
versions: +Python 2.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Mon Oct  2 17:31:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 21:31:47 +0000
Subject: [issue31478] assertion failure in random.seed() in case the seed
 argument has a bad __abs__() method
In-Reply-To: <1505421226.31.0.0993536255685.issue31478@psf.upfronthosting.co.za>
Message-ID: <1506979907.43.0.213398074469.issue31478@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 13da1a60f13e173f65bb0da5ab325641d5bb99ec by Serhiy Storchaka (Oren Milman) in branch '2.7':
[2.7] bpo-31478: Prevent unwanted behavior in _random.Random.seed() in case the arg has a bad __abs__() method (GH-3596) (#3845)
https://github.com/python/cpython/commit/13da1a60f13e173f65bb0da5ab325641d5bb99ec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31478>
_______________________________________

From report at bugs.python.org  Mon Oct  2 17:35:15 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Oct 2017 21:35:15 +0000
Subject: [issue31478] assertion failure in random.seed() in case the seed
 argument has a bad __abs__() method
In-Reply-To: <1505421226.31.0.0993536255685.issue31478@psf.upfronthosting.co.za>
Message-ID: <1506980115.53.0.213398074469.issue31478@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31478>
_______________________________________

From report at bugs.python.org  Mon Oct  2 18:58:24 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 Oct 2017 22:58:24 +0000
Subject: [issue22729] concurrent.futures `wait` and `as_completed` depend on
 private api
In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za>
Message-ID: <1506985104.67.0.213398074469.issue22729@psf.upfronthosting.co.za>


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

any thoughts on this Antoine?

----------
nosy: +gregory.p.smith, pitrou
title: `wait` and `as_completed` depend on private api -> concurrent.futures `wait` and `as_completed` depend on private api

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22729>
_______________________________________

From report at bugs.python.org  Mon Oct  2 19:12:01 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 Oct 2017 23:12:01 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1506985921.01.0.213398074469.issue31415@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Related: https://bugs.python.org/issue31574

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Mon Oct  2 19:15:40 2017
From: report at bugs.python.org (Stephen Moore)
Date: Mon, 02 Oct 2017 23:15:40 +0000
Subject: [issue31660] sys.executable different in os.execv'd python3.6
 virtualenv session in python2 vs python3
In-Reply-To: <1506913947.94.0.213398074469.issue31660@psf.upfronthosting.co.za>
Message-ID: <1506986140.73.0.213398074469.issue31660@psf.upfronthosting.co.za>


Stephen Moore <delfick755 at gmail.com> added the comment:

It appears the problem doesn't appear when using python3 -m venv.

Also it seems __PYVENV_LAUNCHER__ is set to the virtualenv's python except when it's a python3.6 virtualenv and we os.execv from python3.6, where it's set the system python.

Should I be making an issue with the virtualenv project?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31660>
_______________________________________

From report at bugs.python.org  Mon Oct  2 19:23:56 2017
From: report at bugs.python.org (Stephen Moore)
Date: Mon, 02 Oct 2017 23:23:56 +0000
Subject: [issue31660] sys.executable different in os.execv'd python3.6
 virtualenv session in python2 vs python3
In-Reply-To: <1506913947.94.0.213398074469.issue31660@psf.upfronthosting.co.za>
Message-ID: <1506986636.86.0.213398074469.issue31660@psf.upfronthosting.co.za>


Stephen Moore <delfick755 at gmail.com> added the comment:

I just realised python3 sets it's own __PYVENV_LAUNCHER__ and if you unset it before calling to os.execv, then the virtualenv has the correct sys.executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31660>
_______________________________________

From report at bugs.python.org  Mon Oct  2 19:58:59 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Oct 2017 23:58:59 +0000
Subject: [issue30465] FormattedValue expressions have wrong lineno and
 col_offset information
In-Reply-To: <1495666417.53.0.222363680661.issue30465@psf.upfronthosting.co.za>
Message-ID: <1506988739.6.0.213398074469.issue30465@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Is there more to do on this issue or can it be closed now?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30465>
_______________________________________

From report at bugs.python.org  Mon Oct  2 20:02:56 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Oct 2017 00:02:56 +0000
Subject: [issue23404] 'make touch' does not work with git clones of the source
 repository
In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za>
Message-ID: <1506988976.08.0.213398074469.issue23404@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Nick, were you planning to do the work for the other (non-3.6) branches?  If not, can someone else pick this up please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23404>
_______________________________________

From report at bugs.python.org  Mon Oct  2 20:22:53 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Oct 2017 00:22:53 +0000
Subject: [issue31353] Implement PEP 553 - built-in debug()
In-Reply-To: <1504644260.05.0.176716626813.issue31353@psf.upfronthosting.co.za>
Message-ID: <1506990173.08.0.213398074469.issue31353@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

PEP is accepted.  PR needs review.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31353>
_______________________________________

From report at bugs.python.org  Mon Oct  2 20:23:30 2017
From: report at bugs.python.org (Tim Peters)
Date: Tue, 03 Oct 2017 00:23:30 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1506990210.42.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

When Sun was developing fdlibm, I was (among other things) working on a proprietary libm for Kendall Square Research.  I corresponded with fdlibm's primary author (KC Ng) often at the time.  There's no way he would have left errors this egregious slip by, or neglect careful testing near singularities.

But writing portable code at this level is very delicate, and fdlibm failed in many ways when I first compiled it for the KSR machine.  That was the first 64-bit box fdlibm was tried on, & it exposed many unwarranted assumptions in the code.

Browsing the OpenBSD port, they bumped into more, seemingly driven by gcc violating assumptions about how tricky casting would work - there are many places in the code that, e.g., want to view a single double as a pair of int32s (or vice versa), at the bit level.  An aggressive compiler can easily be provoked into reordering operations in fatally damaging ways, if it doesn't realize that, under the maze of cast and union tricks, successive operations are actually operating on the _same_ bits.

So, if possible, it would be great to try compiling OpenBSD's libm with every conceivable optimization disabled, to see if that changes results.

Why I suspect that may be promising:  as Stefan pointed out, for arguments near pi/2 fdlibm's tan() subtracts pi/2 and evaluates the result as tan(x) = -1/tan(x - pi/2).  But these arguments are _so_ close to pi/2 that |x - pi/2| is "tiny".  But for tiny arguments z, tan(z) == z to machine precision (tan(z) = sin(z) / cos(z) ~= z/1 = z for tiny |z|).  So it's effectively using tan(x) = -1/(x - pi/2) in this range.

In the original failing, test, behold:

>>> (1.0 / 1978937966095219.0).hex() # correct
'0x1.234c4c6628b81p-51'

>>> (1.0 / 1978945885716843.0).hex() # OpenBSD
'0x1.234c000000000p-51'

It's very hard to believe all those trailing zero bits in the OpenBSD reciprocal are a coincidence.  It's extremely hard to believe that fdlibm _intended_ them to be all zeroes.  But it's pretty easy to believe an aggressive optimizer managed to lose the intent of the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Mon Oct  2 23:43:00 2017
From: report at bugs.python.org (pdox)
Date: Tue, 03 Oct 2017 03:43:00 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1507002180.05.0.213398074469.issue31622@psf.upfronthosting.co.za>


pdox <pdox at alum.mit.edu> added the comment:

If we don't want to change the type of get_ident(), there is another option.

We could have PyThread keep track of which thread ids (e.g. pthread_t) values are valid (meaning, the thread is still running). This could be tracked in a global data structure (protected by a mutex) internal to PyThread. This can be done automatically for threads created by PyThread, and threads where Python is running (in between PyGILState_Ensure/PyGILState_Release, or other entry functions). If PyThread had this ability, then pthread_kill, etc. could raise an exception when the thread_id is invalid.

The tricky part would be non-Python-created threads. There two obvious options there... one would be to provide explicit PyThread_Register/PyThread_Unregister functions that a thread could call to make itself known to PyThread. The other, would be to allow the use of unsafe thread_id's, as long as an override flag is provided. (e.g. pthread_kill(thread_id, sig, allow_unsafe=True).

To take the abstraction one step further, we could completely hide the OS-level thread identifier inside PyThread, and instead generate our own ids, guaranteeing that they will always be integers. (and perhaps also guaranteeing a higher level of uniqueness)

(This is not so unusual, as pthread_t is itself an abstraction, unrelated to kernel-level thread ids. On linux, the kernel identifies threads using globally unique TIDs, which can be fetched with SYS_gettid. This value does not match pthread_self(). With GLIBC, the value of pthread_t is (usually) a pointer to the bottom of the stack for the thread, which holds a thread descriptor (placed there by pthread_create). For this reason, pthread doesn't mesh well with threads that it didn't create (e.g., calling pthread_self in a thread which was created with clone(), will not do the right thing). pthread_kill is essentially a wrapper around tkill(), which first resolves the pthread_t into a TID.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Tue Oct  3 00:35:20 2017
From: report at bugs.python.org (fireattack)
Date: Tue, 03 Oct 2017 04:35:20 +0000
Subject: [issue31668] "fixFirefoxAnchorBug" function in doctools.js causes
 navigating problem in Py3 doc in Chrome
Message-ID: <1507005320.05.0.213398074469.issue31668@psf.upfronthosting.co.za>


New submission from fireattack <human.peng at gmail.com>:

Problem

This is a regression bug/flaw in Sphinx's doctools.js, a JS file used in its base template, and therefore got inherited to Python 3's documentation website. Python 2's documentation website is not affected because it's based on an older version of Sphinx.

There is a function in doctools.js:

/**
* workaround a firefox stupidity
* see: https://bugzilla.mozilla.org/show_bug.cgi?id=645075
*/
fixFirefoxAnchorBug : function() {
if (document.location.hash)
window.setTimeout(function() {
document.location.href += '';
}, 10);
}


This function was supposed to fix an anchor bug in Firefox (see comment). It *used to* have a condition of $.browser outside, so it will only be applied to Firefox; but it was removed in JQuery so it was removed here as well. Therefore, this function now applies to all the browsers. Unfortunately, it causes navigating problem in Chrome now, when you use back and forward.

The problem STR (Chrome only):

1. Open a link with hash (anchor), e.g. https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str
2. Scroll away from the anchor position.
3. Click any external link (means the link that is not an anchor of current page).
4. Hit "back" button in the browser.

What happened:

When you navigating back, it doesn't go to your previous position. Instead, it goes to the anchor's location.

What it should do:

It should go to your previous position.

Ironically, it won't cause this problem in Firefox, despite it's supposed to be a fix for (a different) anchor bug in Firefox.

Comments

I reported it to Sphinx as well: https://github.com/sphinx-doc/sphinx/issues/3549 but didn't get any response so far.

Please keep in mind the Firefox anchor bug mentioned above will only happen if the anchor is assigned with <section id>. From my observation we don't really use <section> in HTML, so I don't think this workaround function is really necessary here to begin with.

----------
assignee: docs at python
components: Documentation
messages: 303576
nosy: docs at python, fireattack
priority: normal
severity: normal
status: open
title: "fixFirefoxAnchorBug" function in doctools.js causes navigating problem in Py3 doc in Chrome
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31668>
_______________________________________

From report at bugs.python.org  Tue Oct  3 01:50:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 05:50:21 +0000
Subject: [issue31353] Implement PEP 553 - built-in breakpoint()
In-Reply-To: <1504644260.05.0.176716626813.issue31353@psf.upfronthosting.co.za>
Message-ID: <1507009821.37.0.213398074469.issue31353@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: Implement PEP 553 - built-in debug() -> Implement PEP 553 - built-in breakpoint()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31353>
_______________________________________

From report at bugs.python.org  Tue Oct  3 02:02:28 2017
From: report at bugs.python.org (Thomas Jollans)
Date: Tue, 03 Oct 2017 06:02:28 +0000
Subject: [issue31669] string.Template: cods,
 docs and PEP all disagree on definition of identifier
Message-ID: <1507010548.18.0.213398074469.issue31669@psf.upfronthosting.co.za>


New submission from Thomas Jollans <tjol at tjol.eu>:

string.Template matches a $identifier with the regex [_a-z][_a-z0-9]* and re.IGNORECASE. This matches S, ? and s, but not ?. https://github.com/python/cpython/blob/master/Lib/string.py#L78 (this code came up on python-dev)

The docs specify "any case-insensitive ASCII alphanumeric string (including underscores) that starts with an underscore or ASCII letter.". This includes S and s, but neither ? nor ?. https://docs.python.org/3/library/string.html#template-strings

The docs refer to PEP 292, which specifies "By default, 'identifier' must spell a Python identifier [...]" This includes S, ?, s and ?. https://www.python.org/dev/peps/pep-0292/

It's not entirely clear what the correct behaviour is (probably accepting any Python identifier). In any case, the current behaviour of string.Template is a bit silly, but changing it might break stuff.

----------
components: Library (Lib)
messages: 303577
nosy: tjollans
priority: normal
severity: normal
status: open
title: string.Template: cods, docs and PEP all disagree on definition of identifier
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31669>
_______________________________________

From report at bugs.python.org  Tue Oct  3 02:22:26 2017
From: report at bugs.python.org (Brad Nelson)
Date: Tue, 03 Oct 2017 06:22:26 +0000
Subject: [issue31670] Associate .wasm with application/wasm
Message-ID: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>


New submission from Brad Nelson <bradnelson at google.com>:

WebAssembly is tentatively spec'ed to require the application/wasm mime type for download sources:
https://github.com/WebAssembly/design/blob/master/Web.md

The mimetype module should associate .wasm with this mimetype to allow users of SimpleHTTPServer etc. to be able to easily use WebAssembly.

----------
components: IO
messages: 303578
nosy: flagxor
priority: normal
severity: normal
status: open
title: Associate .wasm with application/wasm
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Tue Oct  3 02:41:46 2017
From: report at bugs.python.org (Brad Nelson)
Date: Tue, 03 Oct 2017 06:41:46 +0000
Subject: [issue31670] Associate .wasm with application/wasm
In-Reply-To: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>
Message-ID: <1507012906.97.0.213398074469.issue31670@psf.upfronthosting.co.za>


Change by Brad Nelson <bradnelson at google.com>:


----------
keywords: +patch
pull_requests: +3841
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Tue Oct  3 02:57:58 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 03 Oct 2017 06:57:58 +0000
Subject: [issue31271] an assertion failure in io.TextIOWrapper.write
In-Reply-To: <1503597989.21.0.785820469546.issue31271@psf.upfronthosting.co.za>
Message-ID: <1507013878.42.0.213398074469.issue31271@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

I am not sure, but ISTM that it isn't possible for the encoder to return a
unicode and not fail later.
This is because _textiowrapper_writeflush() would call _io.BytesIO.write()
(after it called _PyBytes_Join()), and bytesio_write() calls PyObject_GetBuffer(),
which would raise "TypeError: 'unicode' does not have the buffer interface".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31271>
_______________________________________

From report at bugs.python.org  Tue Oct  3 02:59:15 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Oct 2017 06:59:15 +0000
Subject: [issue22729] concurrent.futures `wait` and `as_completed` depend on
 private api
In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za>
Message-ID: <1507013955.68.0.213398074469.issue22729@psf.upfronthosting.co.za>


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

This looks like a good idea.  Unfortunately, the patch is most certainly outdated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22729>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:48:30 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Oct 2017 08:48:30 +0000
Subject: [issue31662] trivial typos in Tools/msi/uploadrelease.bat
In-Reply-To: <1506931936.93.0.213398074469.issue31662@psf.upfronthosting.co.za>
Message-ID: <1507020510.34.0.213398074469.issue31662@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset a51c760ddd7ad2513202e419cde90670283a6bc9 by Ned Deily (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31662: Fix typos in uploadrelease.bat script (#3858)
https://github.com/python/cpython/commit/a51c760ddd7ad2513202e419cde90670283a6bc9


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31662>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:48:30 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Oct 2017 08:48:30 +0000
Subject: [issue31423] Error while building PDF documentation
In-Reply-To: <1505159688.48.0.695846604768.issue31423@psf.upfronthosting.co.za>
Message-ID: <1507020510.55.0.912454111764.issue31423@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset a74ce09c738c3e3aa89994bf31049cb914dca389 by Ned Deily (Zachary Ware) in branch '3.6':
[3.6] bpo-31423: Fix building the PDF documentation (GH-3693) (GH-3699)
https://github.com/python/cpython/commit/a74ce09c738c3e3aa89994bf31049cb914dca389


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31423>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:48:30 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Oct 2017 08:48:30 +0000
Subject: [issue31641] concurrent.futures.as_completed() no longer accepts
 arbitrary iterables
In-Reply-To: <1506714570.68.0.213398074469.issue31641@psf.upfronthosting.co.za>
Message-ID: <1507020510.75.0.00913614298617.issue31641@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 2e3fd03796528a9f88f79d38e1d890af153c8e61 by Ned Deily (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31641: Allow arbitrary iterables in `concurrent.futures.as_completed()` (GH-3830) (#3831)
https://github.com/python/cpython/commit/2e3fd03796528a9f88f79d38e1d890af153c8e61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31641>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:51:35 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Oct 2017 08:51:35 +0000
Subject: [issue31641] concurrent.futures.as_completed() no longer accepts
 arbitrary iterables
In-Reply-To: <1506714570.68.0.213398074469.issue31641@psf.upfronthosting.co.za>
Message-ID: <1507020695.3.0.213398074469.issue31641@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Cherry picked into 3.6.3 final -> closing

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31641>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:51:45 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Oct 2017 08:51:45 +0000
Subject: [issue31641] concurrent.futures.as_completed() no longer accepts
 arbitrary iterables
In-Reply-To: <1506714570.68.0.213398074469.issue31641@psf.upfronthosting.co.za>
Message-ID: <1507020705.02.0.213398074469.issue31641@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31641>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:53:59 2017
From: report at bugs.python.org (Ben Mather)
Date: Tue, 03 Oct 2017 08:53:59 +0000
Subject: [issue22729] concurrent.futures `wait` and `as_completed` depend on
 private api
In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za>
Message-ID: <1507020839.22.0.213398074469.issue22729@psf.upfronthosting.co.za>


Ben Mather <bwhmather at bwhmather.com> added the comment:

The patch is indeed a little outdated, but I would be happy to pick it and get it working again.

First we need a resolution to #22630 though.
Currently calling `cancel` will invoke callbacks, but waiters won't be triggered until `set_running_or_notify_cancel` is called.

If both are implemented using the same mechanism, then both will need to be cancelled at the same time.  This means that the behaviour of one the other will need to be changed in a backwards incompatible way.

Does anyone have a preference for where we should send notification of cancellation?
Is the breakage significant enough to kill this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22729>
_______________________________________

From report at bugs.python.org  Tue Oct  3 04:55:57 2017
From: report at bugs.python.org (Julien Palard)
Date: Tue, 03 Oct 2017 08:55:57 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507020957.39.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

For the record, I can reproduce the issue with this minimal test file:

mdk at windhowl$ ls -lah
total 108K
drwxr-xr-x  2 mdk  mdk  4.0K Oct  2 21:15 .
drwxrwxrwt 18 root root  96K Oct  2 21:15 ..
-rw-r--r--  1 mdk  mdk   196 Oct  2 21:13 faq.tex

mdk at windhowl$ cat faq.tex 
\documentclass[a4,10pt,french]{report}

\usepackage[utf8x]{inputenc}
\usepackage[T1,T2A]{fontenc}
\usepackage{babel}

\begin{document}
\tableofcontents
\chapter{FAQ sur Python ?h}
\end{document}

mdk at windhowl$ latexmk faq 2>&1 | tail -n 15
(/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-0.def) [2] (./faq.aux) )
Output written on faq.dvi (2 pages, 608 bytes).
Transcript written on faq.log.
Latexmk: Log file says output to 'faq.dvi'
Rule 'latex': File changes, etc:
   Changed files, or newly in use since previous run(s):
      'faq.aux'
      'faq.toc'
Latexmk: Maximum runs of latex reached without getting stable files
Latexmk: Did not finish processing file 'faq':
   'latex' needed too many passes
Latexmk: Use the -f option to force complete processing,
 unless error was exceeding maximum runs of latex/pdflatex.
Latexmk: applying rule 'latex'...
Latexmk: All targets (faq.dvi) are up-to-date


Also, according to matrixise, it works with xelatex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:33:55 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Oct 2017 09:33:55 +0000
Subject: [issue22729] concurrent.futures `wait` and `as_completed` depend on
 private api
In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za>
Message-ID: <1507023235.97.0.213398074469.issue22729@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22729>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:34:49 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 09:34:49 +0000
Subject: [issue31589] Links for French documentation pdf is broken
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507023289.5.0.213398074469.issue31589@psf.upfronthosting.co.za>


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

Julien: Is there any reason why you want to use utf8x in specific?

https://tex.stackexchange.com/questions/13067/utf8x-vs-utf8-inputenc

"""
utf8x vs. utf8 (inputenc)
(...)
The simple answer is that utf8x is to be avoided if possible. It loads the ucs package, which for a long time was unmaintained (although there is now a new maintainer) and breaks various other things.
"""

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:35:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 09:35:08 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507023308.84.0.213398074469.issue31589@psf.upfronthosting.co.za>


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


----------
title: Links for French documentation pdf is broken -> Links for French documentation PDF is broken: LaTeX issue with non-ASCII characters?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:40:04 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Oct 2017 09:40:04 +0000
Subject: [issue22630] `concurrent.futures.Future.set_running_or_notify_cancel`
 does not notify cancel
In-Reply-To: <1413277554.48.0.992007500484.issue22630@psf.upfronthosting.co.za>
Message-ID: <1507023604.5.0.213398074469.issue22630@psf.upfronthosting.co.za>


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

"change-docs-and-waiters.patch" looks reasonable on the principle, but I doubt it still applies.

Also, we use Github nowadays.  You may still upload patches if you prefer, but pull requests have become the recommended way to submit changes :-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22630>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:41:03 2017
From: report at bugs.python.org (Ben Mather)
Date: Tue, 03 Oct 2017 09:41:03 +0000
Subject: [issue22729] concurrent.futures `wait` and `as_completed` depend on
 private api
In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za>
Message-ID: <1507023663.82.0.213398074469.issue22729@psf.upfronthosting.co.za>


Ben Mather <bwhmather at bwhmather.com> added the comment:

@Nathaniel
RE `remove_done_callback`:  This was added as an optimisation to allow the `as_completed` iterator to remove callbacks for future that it has visited instead of having to store a separate set of visited futures and ignore them when their callbacks are triggered.

This matches how the private waiters mechanism works.

It might be worth submitting the core of this change without `remove_done_callback` and then discussing it later as a separate optimisation.  I will experiment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22729>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:47:48 2017
From: report at bugs.python.org (Julien Palard)
Date: Tue, 03 Oct 2017 09:47:48 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507024068.45.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

I personally do not care about using utf8x, it has been introduced in:

  r74549 | benjamin.peterson | 2009-08-24 12:42:36 -0500 (Mon, 24 Aug 2009) | 1 line
  fix pdf building by teaching latex the right encoding package

  # Get LaTeX to handle Unicode correctly
  latex_elements = {'inputenc': r'\usepackage[utf8x]{inputenc}'}

I tried with utf8 instead and it yielded a different set of errors, so I did not tried much. But utf8-induced bugs may be easier to fix that utf8x-induced bugs, I don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:53:19 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Oct 2017 09:53:19 +0000
Subject: [issue31540] Adding context in concurrent.futures.ProcessPoolExecutor
In-Reply-To: <1505984498.34.0.0119865267465.issue31540@psf.upfronthosting.co.za>
Message-ID: <1507024399.05.0.213398074469.issue31540@psf.upfronthosting.co.za>


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


New changeset e8c368df22c344183627e7ef882bea1683fe6dbe by Antoine Pitrou (Thomas Moreau) in branch 'master':
bpo-31540: Allow passing multiprocessing context to ProcessPoolExecutor (#3682)
https://github.com/python/cpython/commit/e8c368df22c344183627e7ef882bea1683fe6dbe


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31540>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:54:44 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 09:54:44 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507024484.95.0.213398074469.issue31589@psf.upfronthosting.co.za>


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

(Oh sorry, I misunderstand what you wrote. I understood that Python didn't use utf8x yet and you proposed to start using it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct  3 05:58:35 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Oct 2017 09:58:35 +0000
Subject: [issue31540] Adding context in concurrent.futures.ProcessPoolExecutor
In-Reply-To: <1505984498.34.0.0119865267465.issue31540@psf.upfronthosting.co.za>
Message-ID: <1507024715.22.0.213398074469.issue31540@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31540>
_______________________________________

From report at bugs.python.org  Tue Oct  3 06:46:36 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 10:46:36 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507027596.77.0.213398074469.issue31415@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 1a87de7fcfa3c19f08e29047337c350b4a32b259 by INADA Naoki in branch 'master':
bpo-31415: Add `-X importtime` option (GH-3490)
https://github.com/python/cpython/commit/1a87de7fcfa3c19f08e29047337c350b4a32b259


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct  3 06:47:10 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 10:47:10 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507027630.63.0.213398074469.issue31415@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:00:30 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 11:00:30 +0000
Subject: [issue31671] IntFlag makes re.compile slower
Message-ID: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

flags exposed by re module are IntFlag from Python 3.4.

Since it is passed to underlying sre_parse and sre_compile,
tests in loop (e.g. `flags & SRE_FLAG_IGNORECASE`) calls
IntFlag.__and__ and creates new instance everytime.

It makes re.compile() slower.

----------
components: Library (Lib)
messages: 303594
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: IntFlag makes re.compile slower
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:05:28 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 11:05:28 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507028728.75.0.213398074469.issue31671@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +3842
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:13:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 11:13:46 +0000
Subject: [issue31619] Strange error when convert hexadecimal with underscores
 to int
In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za>
Message-ID: <1507029226.66.0.213398074469.issue31619@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 85c0b8941f0c8ef3ed787c9d504712c6ad3eb5d3 by Serhiy Storchaka in branch 'master':
bpo-31619: Fixed a ValueError when convert a string with large number of underscores (#3827)
https://github.com/python/cpython/commit/85c0b8941f0c8ef3ed787c9d504712c6ad3eb5d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31619>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:14:03 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Oct 2017 11:14:03 +0000
Subject: [issue31619] Strange error when convert hexadecimal with underscores
 to int
In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za>
Message-ID: <1507029243.44.0.213398074469.issue31619@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3843

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31619>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:15:40 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 11:15:40 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
Message-ID: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>


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

Currently, strings.Template uses re.IGNORECASE without re.ASCII:

    idpattern = r'[_a-z][_a-z0-9]*'
    flags = _re.IGNORECASE

[a-z] matches against '?' (0x131, DOTLESS I) and '?' (0x17f, LONG S).
It is not intentional, and it makes re.compile slower.

----------
components: Regular Expressions
messages: 303596
nosy: ezio.melotti, inada.naoki, mrabarnett
priority: normal
severity: normal
status: open
title: string.Template should use re.ASCII flag
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:35:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 11:35:06 +0000
Subject: [issue31673] Fix the name of Tkinter's adderrorinfo method
Message-ID: <1507030506.61.0.213398074469.issue31673@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

When the _tkinter module was converted to Argument Clinic in issue20168, the name of the adderrorinfo method was written as "adderrinfo". This error was left unnoticed because there are no tests for this method besides bigmem tests. Today I have ran bigmem tests first time (they require 64-bit system and large amount of memory) and have found this typo. Seems these tests are not ran on any buildbots.

----------
assignee: serhiy.storchaka
components: Tkinter
messages: 303597
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix the name of Tkinter's adderrorinfo method
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31673>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:41:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 11:41:48 +0000
Subject: [issue31673] Fix the name of Tkinter's adderrorinfo method
In-Reply-To: <1507030506.61.0.213398074469.issue31673@psf.upfronthosting.co.za>
Message-ID: <1507030908.45.0.213398074469.issue31673@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3844

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31673>
_______________________________________

From report at bugs.python.org  Tue Oct  3 07:44:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 11:44:09 +0000
Subject: [issue31674] Buildbots: random "Failed to connect to github.com port
 443: Connection timed out" errors
Message-ID: <1507031049.66.0.213398074469.issue31674@psf.upfronthosting.co.za>


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

Sometimes, the "git" step fails on buildbots. ARMv7 Ubuntu 3.x just failed on build 1481, atTue Oct 3 11:14:22 2017:

http://buildbot.python.org/all/builders/ARMv7%20Ubuntu%203.x/builds/1481/steps/git/logs/stdio

git fetch -t https://github.com/python/cpython.git master
(...)
fatal: unable to access 'https://github.com/python/cpython.git/': Failed to connect to github.com port 443: Connection timed out

----------
components: Tests
keywords: buildbot
messages: 303598
nosy: haypo
priority: normal
severity: normal
status: open
title: Buildbots: random "Failed to connect to github.com port 443: Connection timed out" errors
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31674>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:04:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:04:23 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
Message-ID: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There is a memory leak in Tkinter's methods splitlines() and split() when pass a string larger than 2 GiB (when encoded to UTF-8).

----------
components: Tkinter
messages: 303599
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Tkinter: memory leak in splitlines() and split()
type: resource usage
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:04:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:04:33 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507032273.24.0.213398074469.issue31675@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:09:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:09:17 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507032557.27.0.213398074469.issue31675@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Fix the name of Tkinter's adderrorinfo method

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:11:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:11:15 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507032675.74.0.213398074469.issue31415@psf.upfronthosting.co.za>


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

Thank you Naoki for this nice enhancement! Tooling always help to take smart decisions on optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:17:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:17:55 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507033075.08.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue28637. Using IntFlag in the re module impacted the Python startup time. This was "fixed" by getting rid of re in site.py.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:18:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:18:06 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507033086.28.0.213398074469.issue31675@psf.upfronthosting.co.za>


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

Which function? Do you mean split() and splitlist() methods of tkapp? C functions _tkinter_tkapp_split() and _tkinter_tkapp_splitlist().

Do you know how to reproduce the memory leak?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:23:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:23:16 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507033396.38.0.213398074469.issue31671@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:24:49 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:24:49 +0000
Subject: [issue30807] setitimer() can disable timer by mistake
In-Reply-To: <1498765750.02.0.334201584192.issue30807@psf.upfronthosting.co.za>
Message-ID: <1507033489.12.0.213398074469.issue30807@psf.upfronthosting.co.za>


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


----------
pull_requests: +3845

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30807>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:25:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:25:13 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507033513.38.0.213398074469.issue31675@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3846

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:27:35 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:27:35 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507033655.4.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Oh, Python already accepts floating point numbers:

haypo at selma$ ./python
Python 3.7.0a1+ (heads/master-dirty:efb560eee2, Oct  3 2017, 12:15:58) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.compile("[a-z]", flags=re.I).match("A")
<_sre.SRE_Match object; span=(0, 1), match='A'>
>>> re.I
<RegexFlag.IGNORECASE: 2>
>>> re.compile("[a-z]", flags=2).match("A")
<_sre.SRE_Match object; span=(0, 1), match='A'>

# and now a float
>>> re.compile("[a-z]", flags=2.0).match("A")
<_sre.SRE_Match object; span=(0, 1), match='A'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:35:15 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:35:15 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507034115.63.0.213398074469.issue31675@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Just run the bigmem tests with ulimit (after fixing issue31673).

    (ulimit -v 4350000; ./python -m test -vuall -M4G test_tcl)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:37:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:37:59 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507034279.94.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

:) This is due to caching. 2.0 == 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:38:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:38:48 +0000
Subject: [issue31619] Strange error when convert hexadecimal with underscores
 to int
In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za>
Message-ID: <1507034328.84.0.213398074469.issue31619@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b5a630f3dd30ed628e088efe7523e650087adba2 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31619: Fixed a ValueError when convert a string with large number of underscores (GH-3827) (#3863)
https://github.com/python/cpython/commit/b5a630f3dd30ed628e088efe7523e650087adba2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31619>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:40:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:40:12 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507034412.82.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Oh, right. Strange.

>>> re.compile("e", flags=2.0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/haypo/prog/python/master/Lib/re.py", line 240, in compile
    return _compile(pattern, flags)
  File "/home/haypo/prog/python/master/Lib/re.py", line 288, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/haypo/prog/python/master/Lib/sre_compile.py", line 747, in compile
    p = sre_parse.parse(p, flags)
  File "/home/haypo/prog/python/master/Lib/sre_parse.py", line 890, in parse
    p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0)
TypeError: unsupported operand type(s) for &: 'float' and 'int'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:46:07 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:46:07 +0000
Subject: [issue31676] Strange failure in test_cgitb
Message-ID: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

I have found a strange failure when run the bigmem tests.

0:20:19 load avg: 1.04 [116/407/1] test_cgitb
test test_cgitb failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/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/serhiy/py/cpython/Lib/test/test_cgitb.py", line 27, in test_html
    html = cgitb.html(sys.exc_info())
  File "/home/serhiy/py/cpython/Lib/cgitb.py", line 117, in html
    records = inspect.getinnerframes(etb, context)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1483, in getinnerframes
    frameinfo = (tb.tb_frame,) + getframeinfo(tb, context)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 1445, in getframeinfo
    lines, lnum = findsource(frame)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 780, in findsource
    module = getmodule(object, file)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 739, in getmodule
    f = getabsfile(module)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 708, in getabsfile
    _filename = getsourcefile(object) or getfile(object)
  File "/home/serhiy/py/cpython/Lib/inspect.py", line 693, in getsourcefile
    if os.path.exists(filename):
  File "/home/serhiy/py/cpython/Lib/genericpath.py", line 19, in exists
    os.stat(path)
ValueError: embedded null byte

0:20:19 load avg: 1.04 [117/407/2] test_csv -- test_cgitb failed


It is not reproduced when run test_cgitb separately.

----------
messages: 303608
nosy: ezio.melotti, haypo, michael.foord, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Strange failure in test_cgitb
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:47:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:47:37 +0000
Subject: [issue31676] Strange failure in test_cgitb
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507034857.83.0.213398074469.issue31676@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: https://bugs.python.org/file47185/tests-bigmem.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:48:04 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:48:04 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507034884.44.0.213398074469.issue31671@psf.upfronthosting.co.za>


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


----------
pull_requests: +3847

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:50:19 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 12:50:19 +0000
Subject: [issue31669] string.Template: cods,
 docs and PEP all disagree on definition of identifier
In-Reply-To: <1507010548.18.0.213398074469.issue31669@psf.upfronthosting.co.za>
Message-ID: <1507035019.01.0.213398074469.issue31669@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
superseder:  -> string.Template should use re.ASCII flag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31669>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:50:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:50:24 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507035024.78.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

> :) This is due to caching. 2.0 == 2.

I proposed PR 3867 to fix the re.compile() cache: check flags type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:52:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:52:39 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507035159.92.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Victor, how large is performance regression of your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:54:43 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 12:54:43 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507035283.28.0.213398074469.issue31672@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +barry, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:55:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 12:55:38 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507035338.05.0.213398074469.issue31675@psf.upfronthosting.co.za>


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

Oh, Python splitlist() doesn't seem to be documented.

Tcl SplitList documentation: https://www.tcl.tk/man/tcl/TclLib/SplitList.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 08:58:02 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 12:58:02 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
Message-ID: <1507035482.04.0.213398074469.issue31677@psf.upfronthosting.co.za>


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

email.header has this pattern:

https://github.com/python/cpython/blob/85c0b8941f0c8ef3ed787c9d504712c6ad3eb5d3/Lib/email/header.py#L34-L43

# Match encoded-word strings in the form =?charset?q?Hello_World?=                       
ecre = re.compile(r'''                                                                   
  =\?                   # literal =?                                                     
  (?P<charset>[^?]*?)   # non-greedy up to the next ? is the charset                     
  \?                    # literal ?                                                      
  (?P<encoding>[qb])    # either a "q" or a "b", case insensitive                        
  \?                    # literal ?                                                      
  (?P<encoded>.*?)      # non-greedy up to the next ?= is the encoded string             
  \?=                   # literal ?=                                                     
  ''', re.VERBOSE | re.IGNORECASE | re.MULTILINE)


Since only 's' and 'i' has other lower case character, this is not a real bug.
But using re.ASCII is more safe.

Additionally, email.util has same pattern from 10 years ago, and it is not used by anywhere.
It should be removed.

----------
components: Regular Expressions
messages: 303612
nosy: ezio.melotti, inada.naoki, mrabarnett
priority: normal
severity: normal
status: open
title: email.header uses re.IGNORECASE without re.ASCII
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:03:36 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 13:03:36 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
In-Reply-To: <1507035482.04.0.213398074469.issue31677@psf.upfronthosting.co.za>
Message-ID: <1507035816.01.0.213398074469.issue31677@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +3848
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:09:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 13:09:49 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
In-Reply-To: <1507035482.04.0.213398074469.issue31677@psf.upfronthosting.co.za>
Message-ID: <1507036189.28.0.213398074469.issue31677@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Alternatively, re.IGNORECASE can be removed and [qb] replaced with [QqBb].

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:17:15 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 13:17:15 +0000
Subject: [issue31669] string.Template: cods,
 docs and PEP all disagree on definition of identifier
In-Reply-To: <1507010548.18.0.213398074469.issue31669@psf.upfronthosting.co.za>
Message-ID: <1507036635.58.0.213398074469.issue31669@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is no contradiction. PEP 292 means Python 2 identifiers. Python 3 documentation was changed according to changing the definition of Python identifiers (see issue24351).

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31669>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:40:03 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Oct 2017 13:40:03 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
In-Reply-To: <1507035482.04.0.213398074469.issue31677@psf.upfronthosting.co.za>
Message-ID: <1507038003.61.0.213398074469.issue31677@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I think using re.ASCII is a good addition since RFC 2047 says:

   Generally, an "encoded-word" is a sequence of printable ASCII
   characters that begins with "=?", ends with "?=", and has two "?"s in
   between.  It specifies a character set and an encoding method, and
   also includes the original text encoded as graphic ASCII characters,
   according to the rules for that encoding method.

It's better to keep the re.IGNORECASE since the RFC also says:

   Both 'encoding' and 'charset' names are case-independent.  Thus the
   charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
   encoding named "Q" may be spelled either "Q" or "q".

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:47:42 2017
From: report at bugs.python.org (=?utf-8?b?0JzQuNGF0LDQuNC7INCc0LjRgNC+0L3QvtCy?=)
Date: Tue, 03 Oct 2017 13:47:42 +0000
Subject: [issue31678] Incorrect C Function name for timedelta
Message-ID: <1507038462.28.0.213398074469.issue31678@psf.upfronthosting.co.za>


New submission from ?????? ??????? <phobosmir at gmail.com>:

Documentation:

PyDateTime_DELTA_GET_MICROSECOND
https://docs.python.org/3/c-api/datetime.html#c.PyDateTime_DELTA_GET_MICROSECOND

Should be:
PyDateTime_DELTA_GET_MICROSECONDS

----------
assignee: docs at python
components: Documentation
messages: 303616
nosy: docs at python, ?????? ???????
priority: normal
severity: normal
status: open
title: Incorrect C Function name for timedelta
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31678>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:51:37 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 13:51:37 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507038697.63.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Serhiy: "Victor, how large is performance regression of your patch?"

I tested bm_regex_compile.py of the Python performance benchmark suite:
https://pyperformance.readthedocs.io/benchmarks.html#regex-compile

My patch has no impact on *uncached* re.compile() performances according to this benchmark.

haypo at selma$ ./python -m perf compare_to ref.json patch.json  
Benchmark hidden because not significant (1): regex_compile

haypo at selma$ ./python -m perf compare_to ref.json patch.json  -v
Mean +- std dev: [ref] 386 ms +- 6 ms -> [patch] 387 ms +- 6 ms: 1.00x slower (+0%)
Not significant!

--

On a microbenchmark on the *cache* itself, the difference is visible:

 1018  ./python -m perf timeit -s 'import re; re_compile=re.compile' 're_compile("a", flags=2)' --duplicate=1024 -o ref.json  --inherit=PYTHONPATH -v
 1019  git co re_compile_flags_type 
 1020  make
 1021  ./python -m perf timeit -s 'import re; re_compile=re.compile' 're_compile("a", flags=2)' --duplicate=1024 -o patch.json  --inherit=PYTHONPATH -v
 1022  ./python -m perf compare_to ref.json patch.json  
 1023  git diff master..

haypo at selma$ ./python -m perf compare_to ref.json patch.json  
Mean +- std dev: [ref] 364 ns +- 6 ns -> [patch] 459 ns +- 10 ns: 1.26x slower (+26%)

If you replace type(flags) with flags.__class__, the change has no impact on performances :-) But obj.__class__ can be different than type(obj).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 09:51:50 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Oct 2017 13:51:50 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507038710.23.0.213398074469.issue31672@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Technically it *is* an API change since `flags` is a part of the public API.  The documentation says:

    $identifier names a substitution placeholder matching a mapping key of 
    "identifier". By default, "identifier" is restricted to any case-
    insensitive ASCII alphanumeric string (including underscores) that starts 
    with an underscore or ASCII letter. The first non-identifier character 
    after the $ character terminates this placeholder specification.

This means if someone does subclass string.Template and changes the pattern to accept Unicode identifiers, then with this change they will also have to modify flags, whereas before they didn't.

It really wasn't ever the intention to allow non-ASCII identifiers, so this is probably safe in practice.  OTOH, making the change for performance reasons might be questionable, given that the regular expressions are compiled by the Template's metaclass, so unlikely to contribute significantly to overall performance wins.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:00:31 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Oct 2017 14:00:31 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507039231.29.0.213398074469.issue31671@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:21:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 14:21:03 +0000
Subject: [issue31676] Strange failure in test_cgitb
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507040463.02.0.213398074469.issue31676@psf.upfronthosting.co.za>


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

I bisect the bug manually and using test.bisect. I identified that the bug is triggered when you run the following 3 tests:
---
test.test_imp.ImportTests.test_load_source
test.test_cgitb.TestCgitb.test_html
test.test_cgitb.TestCgitb.test_fonts
---

Write these tests into "tests" file and run:

./python -m test.bisect -uall -M4G test_imp test_cgitb --matchfile=tests

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:22:01 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 14:22:01 +0000
Subject: [issue31676] Strange failure in test_cgitb
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507040521.56.0.213398074469.issue31676@psf.upfronthosting.co.za>


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

Sorry, run:

./python -m test -M4G test_imp test_cgitb --matchfile=tests

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:26:41 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Oct 2017 14:26:41 +0000
Subject: [issue31669] string.Template: cods,
 docs and PEP all disagree on definition of identifier
In-Reply-To: <1507010548.18.0.213398074469.issue31669@psf.upfronthosting.co.za>
Message-ID: <1507040801.9.0.213398074469.issue31669@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31669>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:31:32 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 14:31:32 +0000
Subject: [issue31676] Strange failure in test_cgitb
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507041092.74.0.213398074469.issue31676@psf.upfronthosting.co.za>


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

The problem is that imp.load_source() modifies __file__ of the __main__ module.

Example of a file x.py:
---
import imp
import sys
print(sys.modules[__name__])
try:
    imp.load_source(__name__, __file__ + "\0")
except:
    pass
print(sys.modules[__name__])
---

Output:
---
<module '__main__' from 'x.py'>
<module '__main__' from 'x.py\x00'>
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:33:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 14:33:24 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507041204.26.0.213398074469.issue31676@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, eric.snow, ncoghlan
title: Strange failure in test_cgitb -> test.test_imp.ImportTests.test_load_source has side effects
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:35:54 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Tue, 03 Oct 2017 14:35:54 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507041354.68.0.213398074469.issue31567@psf.upfronthosting.co.za>


Change by Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com>:


----------
nosy: +Henk-Jaap Wagenaar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:42:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 14:42:38 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507041758.81.0.213398074469.issue31676@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3849
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:44:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 14:44:08 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507041848.42.0.213398074469.issue31676@psf.upfronthosting.co.za>


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

Attached PR 3871 fixes the side effect in test_imp, but I'm not sure that it's the best fix. Maybe load_source() should use a "transaction" to restore attributes on failure?

load_source() seems to be used imp.reload() for example. Do you expect this function to restore the imported module to its original state on failure?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct  3 10:58:34 2017
From: report at bugs.python.org (Thomas Jollans)
Date: Tue, 03 Oct 2017 14:58:34 +0000
Subject: [issue31669] string.Template: code,
 docs and PEP all disagree on definition of identifier
In-Reply-To: <1507010548.18.0.213398074469.issue31669@psf.upfronthosting.co.za>
Message-ID: <1507042713.99.0.213398074469.issue31669@psf.upfronthosting.co.za>


Thomas Jollans <tjol at tjol.eu> added the comment:

Should the PEP be clarified?

----------
title: string.Template: cods, docs and PEP all disagree on definition of identifier -> string.Template: code, docs and PEP all disagree on definition of identifier

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31669>
_______________________________________

From report at bugs.python.org  Tue Oct  3 11:00:36 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Oct 2017 15:00:36 +0000
Subject: [issue23404] 'make touch' does not work with git clones of the source
 repository
In-Reply-To: <1423262765.96.0.527396909.issue23404@psf.upfronthosting.co.za>
Message-ID: <1507042836.93.0.213398074469.issue23404@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, I'm not currently working on this (to be completely honest, I entirely forgot we hadn't backported the What's New updates to the various branches).

They'll need to be independent updates, since they affect a different file for each release (although they can then be cherry-picked forward into the development branch)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23404>
_______________________________________

From report at bugs.python.org  Tue Oct  3 11:07:13 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Oct 2017 15:07:13 +0000
Subject: [issue31669] string.Template: code,
 docs and PEP all disagree on definition of identifier
In-Reply-To: <1507010548.18.0.213398074469.issue31669@psf.upfronthosting.co.za>
Message-ID: <1507043233.71.0.213398074469.issue31669@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

PEPs aren't really intended to be ongoing specs, keeping up with implementation changes.  The documentation is pretty clear in defining identifiers as "any case-insensitive ASCII alphanumeric string (including underscores) that starts with an underscore or ASCII letter".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31669>
_______________________________________

From report at bugs.python.org  Tue Oct  3 11:20:06 2017
From: report at bugs.python.org (Mironov Mikhail)
Date: Tue, 03 Oct 2017 15:20:06 +0000
Subject: [issue31678] Incorrect C Function name for timedelta
In-Reply-To: <1507038462.28.0.213398074469.issue31678@psf.upfronthosting.co.za>
Message-ID: <1507044006.85.0.213398074469.issue31678@psf.upfronthosting.co.za>


Change by Mironov Mikhail <phobosmir at gmail.com>:


----------
keywords: +patch
pull_requests: +3850
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31678>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:24:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 16:24:45 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507047885.52.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I don't think there is a problem which is worth to be solved by PR 3867. It is very unlikely that anyone uses re functions with a pattern and float flags which accidentally matches already cached valid pattern and integer flag. If float value is passed as a flag it is likely is passed the first time. Fractional floats are rejected in any case. This is different from the problem with PR 3862.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:27:54 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 16:27:54 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507048074.3.0.213398074469.issue31672@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +3851
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:31:54 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 16:31:54 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507048314.33.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> This means if someone does subclass string.Template and changes the pattern to accept Unicode identifiers, then with this change they will also have to modify flags, whereas before they didn't.

Thank you for pointing it out.
I removed re.A flag after compilation.

> OTOH, making the change for performance reasons might be questionable, given that the regular expressions are compiled by the Template's metaclass, so unlikely to contribute significantly to overall performance wins.

original: import time:      2310 |       9589 | string
patched:  import time:      1420 |       8702 | string

We can save about 900 us.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:32:21 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 03 Oct 2017 16:32:21 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507048341.09.0.213398074469.issue31672@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:37:30 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Oct 2017 16:37:30 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507048650.15.0.213398074469.issue31415@psf.upfronthosting.co.za>


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

This is pretty useless on Windows because you are using a clock with 15-16 milli (not micro) second resolution on Windows.  Before Victor introduced time.perf_counter, with decent behavior on all systems, timeit used different time module functions on Windows and *nix because the two different functions had such different behavior on the two systems.  I believe it used time.clock on Windows (1 second resolution of *nix?) and time.time otherwise (.016 sec resolution on Windows).  

Time.monotonic seems to be based on time.time as it has the same low resolution on Windows.  Run something like

for i in range(1000): time.monotonic()

and you will see identical times except for 1 or 2 jumps of .016.  So the C equivalent or time.clock or time.perf_counter is needed on Windows.  Victor can advise as he knows this better than me.

An example of nearly useless output, with 15-16 millisecond resolution.

f:\dev\3x>python -X importtime -c "import idlelib.pyshell"
Running Debug|Win32 interpreter...
import time: self [us] | cumulative | imported package
import time:         0 |          0 |     _codecs
import time:         0 |          0 |   codecs
import time:         0 |          0 |   encodings.aliases
import time:     15000 |      15000 | encodings
import time:         0 |          0 | encodings.utf_8
import time:         0 |          0 | _signal
import time:         0 |          0 | encodings.latin_1
import time:         0 |          0 |     _weakrefset
import time:         0 |          0 |   abc
import time:         0 |          0 | io
import time:         0 |          0 |       _stat
import time:         0 |          0 |     stat
import time:         0 |          0 |       genericpath
import time:         0 |          0 |     ntpath
import time:         0 |          0 |     _collections_abc
import time:     16000 |      16000 |   os
import time:         0 |          0 |   _sitebuiltins
import time:         0 |          0 |   sitecustomize
import time:         0 |          0 |   usercustomize
import time:     16000 |      32000 | site
import time:         0 |          0 |   idlelib
import time:         0 |          0 |       types
import time:         0 |          0 |       _collections
import time:         0 |          0 |     enum
import time:     16000 |      16000 |     _tkinter
import time:         0 |          0 |     tkinter.constants
import time:         0 |          0 |         _sre
import time:         0 |          0 |           sre_constants
import time:         0 |          0 |         sre_parse
import time:         0 |          0 |       sre_compile
import time:         0 |          0 |         _functools
import time:         0 |          0 |             _operator
import time:         0 |          0 |           operator
import time:         0 |          0 |           keyword
import time:         0 |          0 |             _heapq
import time:         0 |          0 |           heapq
import time:         0 |          0 |           itertools
import time:     15000 |      15000 |           reprlib
import time:         0 |      15000 |         collections
import time:         0 |      15000 |       functools
import time:         0 |          0 |       _locale
import time:         0 |          0 |       copyreg
import time:     16000 |      31000 |     re
import time:         0 |      47000 |   tkinter
import time:         0 |          0 |     tkinter.commondialog
import time:     16000 |      16000 |   tkinter.messagebox
import time:         0 |          0 |           token
import time:         0 |          0 |         tokenize
import time:         0 |          0 |       linecache
import time:         0 |          0 |     traceback
import time:     15000 |      15000 |       __future__
import time:         0 |      15000 |     codeop
import time:         0 |      15000 |   code
import time:         0 |          0 |       time
import time:         0 |          0 |       signal
import time:         0 |          0 |       warnings
import time:         0 |          0 |       errno
import time:         0 |          0 |       threading
import time:         0 |          0 |       msvcrt
import time:         0 |          0 |       _winapi
import time:     16000 |      16000 |     subprocess
import time:     16000 |      32000 |   platform
import time:         0 |          0 |     _socket
import time:         0 |          0 |       collections.abc
import time:         0 |          0 |       math
import time:         0 |          0 |       select
import time:         0 |          0 |     selectors
import time:     15000 |      15000 |   socket
import time:     16000 |      16000 |       configparser
import time:         0 |          0 |       tkinter.font
import time:         0 |          0 |       _bootlocale
import time:         0 |          0 |       encodings.cp1252
import time:     31000 |      47000 |     idlelib.config
import time:         0 |          0 |     idlelib.delegator
import time:     63000 |     110000 |   idlelib.colorizer
import time:         0 |          0 |         posixpath
import time:         0 |          0 |       fnmatch
import time:         0 |          0 |           _ast
import time:     15000 |      15000 |         ast
import time:         0 |          0 |             _opcode
import time:         0 |          0 |           opcode
import time:         0 |          0 |         dis
import time:     16000 |      16000 |           importlib
import time:         0 |      16000 |         importlib.machinery
import time:         0 |      31000 |       inspect
import time:         0 |      31000 |     bdb
import time:         0 |          0 |     tkinter.ttk
import time:         0 |          0 |     idlelib.macosx
import time:         0 |          0 |     idlelib.scrolledlist
import time:         0 |          0 |     idlelib.windows
import time:         0 |      31000 |   idlelib.debugger
import time:     16000 |      16000 |   idlelib.debugger_r
import time:         0 |          0 |     importlib.abc
import time:         0 |          0 |       contextlib
import time:         0 |          0 |     importlib.util
import time:         0 |          0 |       _string
import time:     15000 |      15000 |     string
import time:         0 |          0 |       shlex
import time:         0 |          0 |         zlib
import time:         0 |          0 |           _compression
import time:         0 |          0 |           _bz2
import time:     16000 |      16000 |         bz2
import time:         0 |          0 |           _lzma
import time:         0 |          0 |         lzma
import time:         0 |          0 |         pwd
import time:         0 |          0 |         grp
import time:         0 |      16000 |       shutil
import time:         0 |      16000 |     webbrowser
import time:     15000 |      15000 |     tkinter.simpledialog
import time:         0 |          0 |       tkinter.colorchooser
import time:         0 |          0 |       idlelib.config_key
import time:         0 |          0 |           weakref
import time:         0 |          0 |               org
import time:         0 |          0 |             org.python
import time:         0 |          0 |           org.python.core
import time:         0 |          0 |         copy
import time:         0 |          0 |       idlelib.dynoption
import time:         0 |          0 |           tkinter.dialog
import time:     16000 |      16000 |         tkinter.filedialog
import time:         0 |      16000 |       idlelib.query
import time:         0 |          0 |       idlelib.tabbedpages
import time:         0 |          0 |       idlelib.textview
import time:         0 |          0 |           idlelib.multicall
import time:         0 |          0 |         idlelib.autocomplete_w
import time:         0 |          0 |           idlelib.pyparse
import time:     16000 |      16000 |         idlelib.hyperparser
import time:     15000 |      31000 |       idlelib.autocomplete
import time:         0 |          0 |       idlelib.codecontext
import time:         0 |          0 |       idlelib.parenmatch
import time:         0 |          0 |       idlelib.paragraph
import time:         0 |      47000 |     idlelib.configdialog
import time:         0 |          0 |       idlelib.searchbase
import time:         0 |          0 |       idlelib.searchengine
import time:         0 |          0 |     idlelib.grep
import time:     16000 |      16000 |           html.entities
import time:         0 |      16000 |         html
import time:         0 |          0 |         _markupbase
import time:     16000 |      32000 |       html.parser
import time:         0 |      32000 |     idlelib.help
import time:         0 |          0 |     idlelib.help_about
import time:         0 |          0 |     idlelib.replace
import time:         0 |          0 |     idlelib.search
import time:         0 |          0 |       idlelib.redirector
import time:         0 |          0 |     idlelib.percolator
import time:     15000 |      15000 |     idlelib.undo
import time:         0 |          0 |             _hashlib
import time:         0 |          0 |             _blake2
import time:         0 |          0 |             _sha3
import time:         0 |          0 |           hashlib
import time:         0 |          0 |             _bisect
import time:         0 |          0 |           bisect
import time:         0 |          0 |           _random
import time:         0 |          0 |         random
import time:         0 |          0 |       tempfile
import time:     16000 |      16000 |       locale
import time:         0 |      16000 |     idlelib.iomenu
import time:         0 |          0 |     idlelib.mainmenu
import time:         0 |          0 |     idlelib.statusbar
import time:         0 |          0 |     idlelib.autoexpand
import time:     15000 |      15000 |       textwrap
import time:         0 |          0 |       idlelib.calltip_w
import time:         0 |      15000 |     idlelib.calltips
import time:         0 |          0 |     idlelib.rstrip
import time:         0 |          0 |     idlelib.zoomheight
import time:         0 |     171000 |   idlelib.editor
import time:         0 |          0 |   idlelib.filelist
import time:         0 |          0 |   idlelib.outwin
import time:         0 |          0 |         _struct
import time:         0 |          0 |       struct
import time:         0 |          0 |       _compat_pickle
import time:         0 |          0 |           org
import time:         0 |          0 |         org.python
import time:         0 |          0 |       org.python.core
import time:         0 |          0 |       _pickle
import time:         0 |          0 |     pickle
import time:         0 |          0 |     queue
import time:     16000 |      16000 |     socketserver
import time:     16000 |      32000 |   idlelib.rpc
import time:         0 |          0 |     idlelib.debugobj_r
import time:         0 |          0 |         idlelib.tree
import time:         0 |          0 |       idlelib.debugobj
import time:         0 |          0 |     idlelib.stackviewer
import time:         0 |          0 |   idlelib.run
import time:         0 |          0 |   idlelib.history
import time:     30000 |     515000 | idlelib.pyshell

----------
nosy: +terry.reedy
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:39:56 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 03 Oct 2017 16:39:56 +0000
Subject: [issue31668] "fixFirefoxAnchorBug" function in doctools.js causes
 navigating problem in Py3 doc in Chrome
In-Reply-To: <1507005320.05.0.213398074469.issue31668@psf.upfronthosting.co.za>
Message-ID: <1507048796.78.0.213398074469.issue31668@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Is there anything to be done in CPython? It appears to be either a bug with the browser or Sphinx...

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31668>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:46:58 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 03 Oct 2017 16:46:58 +0000
Subject: [issue31657] unit test for optimization levels does not cover
 __debug__ case
In-Reply-To: <1506870513.15.0.213398074469.issue31657@psf.upfronthosting.co.za>
Message-ID: <1507049218.42.0.213398074469.issue31657@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 543386b7f077d210ea0722079d68beb6c066730a by Mariatta (diana) in branch 'master':
bpo-31657: Add test coverage for the __debug__ case (GH-3450)
https://github.com/python/cpython/commit/543386b7f077d210ea0722079d68beb6c066730a


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31657>
_______________________________________

From report at bugs.python.org  Tue Oct  3 12:50:51 2017
From: report at bugs.python.org (fireattack)
Date: Tue, 03 Oct 2017 16:50:51 +0000
Subject: [issue31668] "fixFirefoxAnchorBug" function in doctools.js causes
 navigating problem in Py3 doc in Chrome
In-Reply-To: <1507005320.05.0.213398074469.issue31668@psf.upfronthosting.co.za>
Message-ID: <1507049451.32.0.213398074469.issue31668@psf.upfronthosting.co.za>


fireattack <human.peng at gmail.com> added the comment:

Well, since it affects Python's site's functionality, I thought it's appropriate to report here (with components: documentation). I followed the instruction here: https://docs.python.org/3/bugs.html#documentation-bugs

It is not Sphinx's bug per se, since it has nothing to do with its software; just an ancient problematic script in template got copied here. 

It is not a Chrome bug, since that script was not intended to apply to Chrome to begin with.

But anyway, if anyone found it's not the right place, feel free to close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31668>
_______________________________________

From report at bugs.python.org  Tue Oct  3 13:04:18 2017
From: report at bugs.python.org (John Brearley)
Date: Tue, 03 Oct 2017 17:04:18 +0000
Subject: [issue31679] pydot missing write, write_png, etc
Message-ID: <1507050258.25.0.213398074469.issue31679@psf.upfronthosting.co.za>


New submission from John Brearley <brearley at magma.ca>:

I have successfully installed Graphviz tool from http://graphviz.org, updated my PATH variable appropriately and can generate .PNG files using Python module Graphviz with WinPython 3.6.1. However, I cannot get anywhere using the pydot V1.2.3 module in the same environment. 

The online help suggests that there there are write & write_png members but I can find no trace of them. My sample script is attached. The error I get is:

Traceback (most recent call last):
  File "ML_ex2.py", line 109, in <module>
    graph.write(path=out_fn, format="png")
AttributeError: 'list' object has no attribute 'write'

----------
components: Extension Modules
files: ML_ex2.py
messages: 303632
nosy: jbrearley
priority: normal
severity: normal
status: open
title: pydot missing write, write_png, etc
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47186/ML_ex2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31679>
_______________________________________

From report at bugs.python.org  Tue Oct  3 13:13:31 2017
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Oct 2017 17:13:31 +0000
Subject: [issue31679] pydot missing write, write_png, etc
In-Reply-To: <1507050258.25.0.213398074469.issue31679@psf.upfronthosting.co.za>
Message-ID: <1507050811.93.0.213398074469.issue31679@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

pydot is not part of the standard library; you'll need to find their issue tracker (looks like maybe https://github.com/erocarrera/pydot/issues?) and open a ticket there.

----------
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31679>
_______________________________________

From report at bugs.python.org  Tue Oct  3 14:11:25 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Oct 2017 18:11:25 +0000
Subject: [issue31670] Associate .wasm with application/wasm
In-Reply-To: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>
Message-ID: <1507054285.09.0.213398074469.issue31670@psf.upfronthosting.co.za>


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

We generally wait for something a bit stronger than "tentatively" before adding a mime type (ie: an actual submission to the relevant standards channel).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Tue Oct  3 14:20:43 2017
From: report at bugs.python.org (Jonathan Abdo)
Date: Tue, 03 Oct 2017 18:20:43 +0000
Subject: [issue31583] 2to3 call for file in current directory yields error
In-Reply-To: <1506401881.51.0.156968615835.issue31583@psf.upfronthosting.co.za>
Message-ID: <1507054843.95.0.213398074469.issue31583@psf.upfronthosting.co.za>


Jonathan Abdo <jfabdo at gmail.com> added the comment:

Issue also effects 3.5

----------
nosy: +jabdo
versions: +Python 3.5
Added file: https://bugs.python.org/file47187/2to3bugpython.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31583>
_______________________________________

From report at bugs.python.org  Tue Oct  3 14:27:26 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Oct 2017 18:27:26 +0000
Subject: [issue31583] 2to3 call for file in current directory yields error
In-Reply-To: <1506401881.51.0.156968615835.issue31583@psf.upfronthosting.co.za>
Message-ID: <1507055246.49.0.213398074469.issue31583@psf.upfronthosting.co.za>


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

3.5 is in security-fix-only mode, and we use versions to indicate which versions we plan to fix the bug in.

----------
nosy: +r.david.murray
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31583>
_______________________________________

From report at bugs.python.org  Tue Oct  3 14:29:33 2017
From: report at bugs.python.org (Jonathan Abdo)
Date: Tue, 03 Oct 2017 18:29:33 +0000
Subject: [issue31583] 2to3 call for file in current directory yields error
In-Reply-To: <1507055246.49.0.213398074469.issue31583@psf.upfronthosting.co.za>
Message-ID: <CAK=qUxE9B2hTbMEypH5APAu8AfKThRxDYrDeYj1Qbv0-nvE5Dw@mail.gmail.com>


Jonathan Abdo <jfabdo at gmail.com> added the comment:

Gotcha, sorry about that. Active uses 3.5, so I guess I would take it up
with them?

On Oct 3, 2017 2:27 PM, "R. David Murray" <report at bugs.python.org> wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> 3.5 is in security-fix-only mode, and we use versions to indicate which
> versions we plan to fix the bug in.
>
> ----------
> nosy: +r.david.murray
> versions:  -Python 3.5
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31583>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31583>
_______________________________________

From report at bugs.python.org  Tue Oct  3 14:37:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 18:37:24 +0000
Subject: [issue31673] Fix the name of Tkinter's adderrorinfo method
In-Reply-To: <1507030506.61.0.213398074469.issue31673@psf.upfronthosting.co.za>
Message-ID: <1507055844.82.0.213398074469.issue31673@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 929b40a601db868530d6beaafb3256822103a7fb by Serhiy Storchaka in branch 'master':
bpo-31673: Fixed typo in the name of Tkinter's method adderrorinfo(). (#3864)
https://github.com/python/cpython/commit/929b40a601db868530d6beaafb3256822103a7fb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31673>
_______________________________________

From report at bugs.python.org  Tue Oct  3 14:55:21 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Oct 2017 18:55:21 +0000
Subject: [issue31583] 2to3 call for file in current directory yields error
In-Reply-To: <1506401881.51.0.156968615835.issue31583@psf.upfronthosting.co.za>
Message-ID: <1507056921.1.0.213398074469.issue31583@psf.upfronthosting.co.za>


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

Yes, redistributors sometimes backport non-security fixes if they consider them important enough.

Note that I haven't evaluated the merits of this issue, and there is a related issue about how 2to3 finds its fixers that this may overlap with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31583>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:04:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 19:04:03 +0000
Subject: [issue31673] Fix the name of Tkinter's adderrorinfo method
In-Reply-To: <1507030506.61.0.213398074469.issue31673@psf.upfronthosting.co.za>
Message-ID: <1507057443.23.0.213398074469.issue31673@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3852

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31673>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:39:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 19:39:02 +0000
Subject: [issue31680] Expose curses library name and version on Python level
Message-ID: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The name and the version of the curses library are needed for work around bugs in old versions or skip tests on platforms that provide broken curses library (like OpenBSD providing ncurses 5.7).

The curses and _curses modules provide the attribute "version" (= b'2.2'), but this is just a version of the module.

----------
components: Extension Modules
messages: 303640
nosy: serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Expose curses library name and version on Python level
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:39:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 19:39:40 +0000
Subject: [issue31673] Fix the name of Tkinter's adderrorinfo method
In-Reply-To: <1507030506.61.0.213398074469.issue31673@psf.upfronthosting.co.za>
Message-ID: <1507059580.17.0.213398074469.issue31673@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fcc832a4fafcbbaca5484ed0274935e14c9dcf6b by Serhiy Storchaka in branch '3.6':
[3.6] bpo-31673: Fixed typo in the name of Tkinter's method adderrorinfo(). (GH-3864). (#3873)
https://github.com/python/cpython/commit/fcc832a4fafcbbaca5484ed0274935e14c9dcf6b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31673>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:39:44 2017
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 03 Oct 2017 19:39:44 +0000
Subject: [issue31681] pkgutil.get_data() leaks open files in Python 2.7
Message-ID: <1507059584.22.0.213398074469.issue31681@psf.upfronthosting.co.za>


New submission from Elvis Pranskevichus <elvis at magic.io>:

pkgutil.get_data() does this:

     def get_data(self, pathname):
        return open(pathname, "rb").read()

which very obviously leaks open file descriptors.  This has been fixed in 3.x by https://github.com/python/cpython/commit/1ab58dfb12dedb7, but never backported to 2.7.

----------
components: Library (Lib)
messages: 303642
nosy: Elvis.Pranskevichus
priority: normal
severity: normal
status: open
title: pkgutil.get_data() leaks open files in Python 2.7
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31681>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:39:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 19:39:58 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507059598.39.0.213398074469.issue31675@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 27c623c845dd6e4b8e1782666ca3a956636da266 by Serhiy Storchaka in branch 'master':
bpo-31675: Fix memory leaks in Tkinter's methods splitlist() and split() (#3866)
https://github.com/python/cpython/commit/27c623c845dd6e4b8e1782666ca3a956636da266


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:40:09 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Oct 2017 19:40:09 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507059609.91.0.213398074469.issue31675@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3853

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:41:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 19:41:26 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507059686.08.0.213398074469.issue31680@psf.upfronthosting.co.za>


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

How can we get the ncurses version?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:44:04 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 19:44:04 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507059844.65.0.213398074469.issue31680@psf.upfronthosting.co.za>


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

On Fedora 26, /usr/include/ncurses/curses.h contains:
---
/* These are defined only in curses.h, and are used for conditional compiles */
#define NCURSES_VERSION_MAJOR 6
#define NCURSES_VERSION_MINOR 0
#define NCURSES_VERSION_PATCH 20170212

/* This is defined in more than one ncurses header, for identification */
#undef  NCURSES_VERSION
#define NCURSES_VERSION "6.0"

/*
 * Identify the mouse encoding version.
 */
#define NCURSES_MOUSE_VERSION 2
---

You want to expose such versions? Do you know if there are "curses" implementations different than GNU ncurses?
https://www.gnu.org/software/ncurses/

I'm asking to know how other implementations expose their versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:44:11 2017
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 03 Oct 2017 19:44:11 +0000
Subject: [issue31681] pkgutil.get_data() leaks open files in Python 2.7
In-Reply-To: <1507059584.22.0.213398074469.issue31681@psf.upfronthosting.co.za>
Message-ID: <1507059851.79.0.213398074469.issue31681@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
keywords: +patch
pull_requests: +3854
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31681>
_______________________________________

From report at bugs.python.org  Tue Oct  3 15:45:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 19:45:23 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507059923.58.0.213398074469.issue31680@psf.upfronthosting.co.za>


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

> The name and the version of the curses library are needed for work around bugs in old versions or skip tests on platforms that provide broken curses library (like OpenBSD providing ncurses 5.7).

If there are known issues depending on the ncurses version, it may help to export this version in the test.pythoninfo utility. Do you have an example of known bug? Do we already skip tests depending on the ncurses version?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Tue Oct  3 16:14:56 2017
From: report at bugs.python.org (Jonathan Abdo)
Date: Tue, 03 Oct 2017 20:14:56 +0000
Subject: [issue31583] 2to3 call for file in current directory yields error
In-Reply-To: <1506401881.51.0.156968615835.issue31583@psf.upfronthosting.co.za>
Message-ID: <1507061696.18.0.213398074469.issue31583@psf.upfronthosting.co.za>


Jonathan Abdo <jfabdo at gmail.com> added the comment:

Inserting (with 12 spaces)

            if not output_dir:
                output_dir = "./"

at lines 83 and 84 works as a temporary workaround.  `StdoutRefactoringTool` is not receiving an `output_dir` from `option`, which seems to only be an issue when `--add-sufix` is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31583>
_______________________________________

From report at bugs.python.org  Tue Oct  3 16:50:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 20:50:48 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507063848.09.0.213398074469.issue31675@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a65b2420f681c45db43e94bfe3dc50ad1dfcd03d by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31675: Fix memory leaks in Tkinter's methods splitlist() and split() (GH-3866) (#3874)
https://github.com/python/cpython/commit/a65b2420f681c45db43e94bfe3dc50ad1dfcd03d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:33:05 2017
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Oct 2017 21:33:05 +0000
Subject: [issue31623] Allow to build MSI installer from the official tarball
In-Reply-To: <1506646876.94.0.213398074469.issue31623@psf.upfronthosting.co.za>
Message-ID: <1507066385.94.0.213398074469.issue31623@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As 3.4 is in security-fix-only mode, it's up to Larry whether this can be merged.  The patch looks fine as far as I can tell, but I can't test it.

Note, though, that you are likely to be the only person on Earth using this installer, since there will be no more binary releases of 3.4, the installer was swapped out for 3.5, and the maintainer of the old installer has been away for several years now.  The new installer (in use since 3.5.0) almost certainly doesn't suffer from this issue.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31623>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:36:59 2017
From: report at bugs.python.org (Monica)
Date: Tue, 03 Oct 2017 21:36:59 +0000
Subject: [issue31682] Exception: Cannot import `win32api`!
Message-ID: <1507066619.6.0.213398074469.issue31682@psf.upfronthosting.co.za>


New submission from Monica <maolvera93 at gmail.com>:

Hello, I'm a newbie at Python. I am trying to download Twister to be able to run hardware tests, and it gives me Exception: Cannot import `win32api`!.
I downloaded 'win32_221' and added it to C:\Python27\Scripts

It is still giving me the same error.

This is what I got

TWISTER_PATH is set to `C:\Users\user\Documents\Twister-git_hub_branch\client\executionprocess`.

Traceback (most recent call last):
  File "C:\Users\user\Documents\Twister-git_hub_branch\client\executionprocess\ExecutionProcess.py", line 1563, in <module>
    raise Exception('Cannot import `win32api`!\n')
Exception: Cannot import `win32api`!

----------
components: Installation
messages: 303650
nosy: maolvera
priority: normal
severity: normal
status: open
title: Exception: Cannot import `win32api`!
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31682>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:40:12 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 03 Oct 2017 21:40:12 +0000
Subject: [issue31683] a stack overflow on windows in
 faulthandler._fatal_error()
Message-ID: <1507066812.21.0.213398074469.issue31683@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

On my 64-bit Windows 10, the echo here would print -1073741571:
python -c "import faulthandler; faulthandler._fatal_error(b'a' * 2 ** 22)"
echo %errorlevel%

This is code c00000fd, which windbg describes as 'Stack overflow'.
This happens because Py_FatalError() (in Python/pylifecycle.c) does the following
(on Windows only):
    len = strlen(msg);

    /* Convert the message to wchar_t. This uses a simple one-to-one
    conversion, assuming that the this error message actually uses ASCII
    only. If this ceases to be true, we will have to convert. */
    buffer = alloca( (len+1) * (sizeof *buffer));
    for( i=0; i<=len; ++i)
        buffer[i] = msg[i];


Note that (IIUC) running the aforementioned cmd wouldn't cause a post-mortem
debugger to pop-up, because faulthandler_fatal_error_py()
(in Modules/faulthandler.c) first calls faulthandler_suppress_crash_report(),
and then calls Py_FatalError().

----------
components: Extension Modules
messages: 303651
nosy: Oren Milman, haypo
priority: normal
severity: normal
status: open
title: a stack overflow on windows in faulthandler._fatal_error()
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31683>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:41:15 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 21:41:15 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507066875.49.0.213398074469.issue31675@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3855

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:44:00 2017
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Oct 2017 21:44:00 +0000
Subject: [issue31682] Exception: Cannot import `win32api`!
In-Reply-To: <1507066619.6.0.213398074469.issue31682@psf.upfronthosting.co.za>
Message-ID: <1507067040.56.0.213398074469.issue31682@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

win32api is part of the third-party pywin32 package, which is most easily installed by running `C:\Python27\python.exe -m pip install pypiwin32`.  For further assistance, please try either the comp.lang.python list at python-list at python.org, the pywin32 list at python-win32 at python.org, or the #python channel on freenode.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31682>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:44:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 21:44:46 +0000
Subject: [issue31673] Fix the name of Tkinter's adderrorinfo method
In-Reply-To: <1507030506.61.0.213398074469.issue31673@psf.upfronthosting.co.za>
Message-ID: <1507067086.31.0.213398074469.issue31673@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31673>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:46:21 2017
From: report at bugs.python.org (Aaron Meurer)
Date: Tue, 03 Oct 2017 21:46:21 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
Message-ID: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>


New submission from Aaron Meurer <asmeurer at gmail.com>:

>>> '{:+.19e}'.format(0.)
'+0.0000000000000000000e+00'
>>> import decimal
>>> '{:+.19e}'.format(decimal.Decimal(0))
'+0.0000000000000000000e+19'

Note the decimal uses e+19 instead of e+00. Obviously it's still mathematically correct, but it's annoying to have anything other than e+00 for a 0 value.

----------
messages: 303653
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Scientific formatting of decimal 0 different from float 0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Tue Oct  3 17:54:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 21:54:35 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507067675.78.0.213398074469.issue31680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, this is what I meant. The version should be exposed as a tuple (major, minor, patch) or as a special named tuple. I don't know what to do with other implementations. NCURSES_VERSION_MAJOR is not a part of standard. One solution -- set the version to (0, 0, 0) for unknown implementations. Or expose ncurses version as optional ncurses_version, and expose versions for other known implementations with different names.

A known bug is issue15037. We still don't skip tests depending on the ncurses version because there is no easy way to determine the ncurses version in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Tue Oct  3 18:07:23 2017
From: report at bugs.python.org (Joe Tsai)
Date: Tue, 03 Oct 2017 22:07:23 +0000
Subject: [issue31557] tarfile: incorrectly treats regular file as directory
In-Reply-To: <1506116521.84.0.445900877205.issue31557@psf.upfronthosting.co.za>
Message-ID: <1507068443.11.0.213398074469.issue31557@psf.upfronthosting.co.za>


Joe Tsai <joetsai at google.com> added the comment:

This bug is not platform specific.

I've attached a reproduction:
$ python
>>> import tarfile
>>> tarfile.open("test.tar", "r").next().isdir()
True

$ tar -tvf test.tar
-rw-rw-r-- 0/0               0 1969-12-31 16:00 123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/foo.txt
$ tar --version
tar (GNU tar) 1.27.1

For some background, this bug was original filed against the Go standard library (for which I am the maintainer of the Go implementation of tar). When I investigated the issue, I discovered that Go was doing the right thing, and that the discrepancy was due to the check I pointed to earlier. The GNU tool indicates that this is a regular file as well.

----------
Added file: https://bugs.python.org/file47188/test.tar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31557>
_______________________________________

From report at bugs.python.org  Tue Oct  3 18:11:19 2017
From: report at bugs.python.org (Monica)
Date: Tue, 03 Oct 2017 22:11:19 +0000
Subject: [issue31685] Cannot connect to CE path `127.0.0.1:8010`
Message-ID: <1507068679.1.0.213398074469.issue31685@psf.upfronthosting.co.za>


New submission from Monica <maolvera93 at gmail.com>:

Is there any reason it cannot connect to CE path?

C:\Users\Documents\Twister-git_hub_branch\client\executionprocess>ExecutionProcess.py -u user -e EP-name -s 127.0.0.1:8010

TWISTER_PATH is set to `C:\Users\Documents\Twister-git_hub_branch\client\executionprocess`.

Catching `Ctrl + C` signal OK.

Portable mode: Appending `C:\Users\Documents\Twister-git_hub_branch` to python path.

EP Info: Connecting to the Central Engine...
*ERROR* Cannot connect to CE path `127.0.0.1:8010`! Exiting!
Cannot connect to server! Farewell!

----------
components: Demos and Tools
messages: 303656
nosy: maolvera
priority: normal
severity: normal
status: open
title: Cannot connect to CE path `127.0.0.1:8010`
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31685>
_______________________________________

From report at bugs.python.org  Tue Oct  3 18:51:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 22:51:23 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507071083.93.0.213398074469.issue31680@psf.upfronthosting.co.za>


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

I suggest:

curses._NCURSES_VERSION_INFO = (6, 0, 20170212)
curses._NCURSES_VERSION = "6.0"
curses._NCURSES_MOUSE_VERSION = 2

Similar example, the readline module uses:

    PyModule_AddIntConstant(m, "_READLINE_VERSION", RL_READLINE_VERSION);
    PyModule_AddIntConstant(m, "_READLINE_RUNTIME_VERSION", rl_readline_version);
    PyModule_AddStringConstant(m, "_READLINE_LIBRARY_VERSION", rl_library_version);

readline has two famous implementations: GNU readline and editline. editline reuses GNU readline constants, but the string mentions "editline". Example on macOS El Capitain (test.pythoninfo output):

readline._READLINE_LIBRARY_VERSION: EditLine wrapper
readline._READLINE_RUNTIME_VERSION: 0x402
readline._READLINE_VERSION: 0x402

http://buildbot.python.org/all/builders/x86-64%20El%20Capitan%203.x/builds/871/steps/pythoninfo/logs/stdio

I'm not sure that it's useful to make versions public. I suggest to start with private versions, since we only plan to use them in tests right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Tue Oct  3 18:53:06 2017
From: report at bugs.python.org (Brad Nelson)
Date: Tue, 03 Oct 2017 22:53:06 +0000
Subject: [issue31670] Associate .wasm with application/wasm
In-Reply-To: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>
Message-ID: <1507071186.53.0.213398074469.issue31670@psf.upfronthosting.co.za>


Brad Nelson <bradnelson at google.com> added the comment:

Tentative might be an understatement.
There was 4 browser sign-off on using that mime type within the WebAssembly CG, which has drafted the spec so far.
We're in the process of handing v1 of the spec off to the WebAssembly Working Group on our way to a good and proper W3C REC.
However, use of the mime type is already shipping in Chrome and I believe on the way with other browsers (and just got added to our shared toolchain).

That said we should get a proper allocation with IANA.
I've added an agenda item to our next Working Group meeting to have the group explicitly empower me to approach IANA:
https://github.com/WebAssembly/meetings/blob/master/2017/WG-10-23.md

Be back in month with a IANA request email to reference.

Assuming we've sorted out a proper allocation, do you have a sense of if getting the file type into python2.7 is likely?

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:11:13 2017
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Oct 2017 23:11:13 +0000
Subject: [issue31685] Cannot connect to CE path `127.0.0.1:8010`
In-Reply-To: <1507068679.1.0.213398074469.issue31685@psf.upfronthosting.co.za>
Message-ID: <1507072273.62.0.213398074469.issue31685@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This issue does not appear to have anything to do with the CPython interpreter or standard library, and this issue tracker is not a help forum.  Please try python-list at python.org for assistance, but you'll need to provide the other users of the list significantly more detail about what you're trying to do and how to get any kind of meaningful help.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31685>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:11:26 2017
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Oct 2017 23:11:26 +0000
Subject: [issue31685] Cannot connect to CE path `127.0.0.1:8010`
In-Reply-To: <1507068679.1.0.213398074469.issue31685@psf.upfronthosting.co.za>
Message-ID: <1507072286.68.0.213398074469.issue31685@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components:  -Demos and Tools
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31685>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:12:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Oct 2017 23:12:25 +0000
Subject: [issue31670] Associate .wasm with application/wasm
In-Reply-To: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>
Message-ID: <1507072345.89.0.213398074469.issue31670@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, updates of the mimetype database usually are backported to 2.7.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:20:18 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Oct 2017 23:20:18 +0000
Subject: [issue31670] Associate .wasm with application/wasm
In-Reply-To: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>
Message-ID: <1507072818.23.0.213398074469.issue31670@psf.upfronthosting.co.za>


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

Yes, if/when it goes in it will go in to all currently maintained versions.  I've adjusted 'versions' accordingly.

----------
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:48:08 2017
From: report at bugs.python.org (Jake Lever)
Date: Tue, 03 Oct 2017 23:48:08 +0000
Subject: [issue31686] GZip library doesn't properly close files
Message-ID: <1507074488.46.0.213398074469.issue31686@psf.upfronthosting.co.za>


New submission from Jake Lever <jake.lever at gmail.com>:

The attached code is designed to output compressed data to a gzip file. It creates two GzipFile objects, but only one is really used. It seems that it doesn't clean up and close the file properly.

In Py2, the attached code will fail. The output file (debug.txt.gz) will be corrupt. However if the self.unused line is commented out, it works and the file is not corrupted.

In Py3, a sys.exit call at the end is required to see the same behaviour.


As example output, when the sys.exit is include in Py3, the output is below and the file is corrupt.
Compressor.__init__
UnusedClass.write
UnusedClass.write
UnusedClass.write
UnusedClass.write
UnusedClass.write
UnusedClass.write
Compressor.compressToFile

And when the sys.exit is commented out, the console output is below and the file is not corrupt.

Compressor.__init__
UnusedClass.write
UnusedClass.write
UnusedClass.write
UnusedClass.write
UnusedClass.write
UnusedClass.write
Compressor.compressToFile
UnusedClass.write
UnusedClass.write
UnusedClass.write

----------
files: gzipBug.py
messages: 303662
nosy: Jake Lever
priority: normal
severity: normal
status: open
title: GZip library doesn't properly close files
type: behavior
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file47189/gzipBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31686>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:54:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 23:54:54 +0000
Subject: [issue31683] a stack overflow on windows in
 faulthandler._fatal_error()
In-Reply-To: <1507066812.21.0.213398074469.issue31683@psf.upfronthosting.co.za>
Message-ID: <1507074894.29.0.213398074469.issue31683@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3856
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31683>
_______________________________________

From report at bugs.python.org  Tue Oct  3 19:57:13 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Oct 2017 23:57:13 +0000
Subject: [issue31683] a stack overflow on windows in
 faulthandler._fatal_error()
In-Reply-To: <1507066812.21.0.213398074469.issue31683@psf.upfronthosting.co.za>
Message-ID: <1507075033.8.0.213398074469.issue31683@psf.upfronthosting.co.za>


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

I proposed PR 3878 to replace alloca() with a fixed buffer of 256 bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31683>
_______________________________________

From report at bugs.python.org  Tue Oct  3 21:02:11 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 01:02:11 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507078931.25.0.213398074469.issue31415@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

https://github.com/python/cpython/blob/27c623c845dd6e4b8e1782666ca3a956636da266/Modules/timemodule.c#L80-L112

time module has perf_counter implementation based on QueryPerformanceCounter().

Could we change PyTime_GetMonotonicClock implementation to use it on Windows?

I don't want to so much code to import.c.  But if pytime.c has nice clock
for fine grained monotonic performance counter, I want to use it in
import.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct  3 21:14:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 01:14:45 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507079685.09.0.213398074469.issue31415@psf.upfronthosting.co.za>


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

> Could we change PyTime_GetMonotonicClock implementation to use it on Windows?

No. See the PEP 418 for the rationale.

But we could add a _PyTime_GetPerfCounter() to Python/pytime.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct  3 21:58:26 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Oct 2017 01:58:26 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507082306.94.0.213398074469.issue31671@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

When proposing to undo recent decisions, please add the people to the nosy list who were involved in making that decision in the first place.

----------
nosy: +ethan.furman, gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 22:03:20 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 02:03:20 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507082600.89.0.213398074469.issue31671@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> When proposing to undo recent decisions, please add the people to the nosy list who were involved in making that decision in the first place.

I don't propose reverting IntFlag.
I just propose convert IntFlag to int in re module, before passing it to sre_compile.
So this change is not visible to re users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Tue Oct  3 23:47:41 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 03:47:41 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
In-Reply-To: <1507035482.04.0.213398074469.issue31677@psf.upfronthosting.co.za>
Message-ID: <1507088861.16.0.213398074469.issue31677@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset bf477a99e0c85258e6573f4ee9eda68fa1f98a31 by INADA Naoki in branch 'master':
bpo-31677: email: Remove re.IGNORECASE flag (GH-3868)
https://github.com/python/cpython/commit/bf477a99e0c85258e6573f4ee9eda68fa1f98a31


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Tue Oct  3 23:51:53 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 03:51:53 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
In-Reply-To: <1507035482.04.0.213398074469.issue31677@psf.upfronthosting.co.za>
Message-ID: <1507089113.55.0.213398074469.issue31677@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> It's better to keep the re.IGNORECASE since the RFC also says:
>
>   Both 'encoding' and 'charset' names are case-independent.  Thus the
>   charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
>   encoding named "Q" may be spelled either "Q" or "q".

I'm sorry, I've committed before reading this.
But I think it's not problem, because re.IGNORECASE doesn't affect to
"(?P<charset>[^?]*?)" pattern.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Wed Oct  4 01:34:38 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Oct 2017 05:34:38 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507095278.72.0.213398074469.issue31672@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

When optimizing, please don't make API changes.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 01:39:16 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Oct 2017 05:39:16 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507095556.07.0.213398074469.issue31684@psf.upfronthosting.co.za>


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


----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 01:55:22 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 05:55:22 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507096522.21.0.213398074469.issue31672@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yet one way -- make re.ASCII a local flag. Than we could just change the idpattern attribute to r'(?a:[_a-z][_a-z0-9]*)', without touching the flags attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 02:23:48 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Oct 2017 06:23:48 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507098228.05.0.213398074469.issue31684@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The aim here is to capture the original Decimal value where possible, including the exponent information. (Unlike floats, trailing zeros in a `Decimal` instance are significant.)

>>> from decimal import Decimal
>>> Decimal('+0.0000000000000000000e+19')
Decimal('0')
>>> Decimal('+0.0000000000000000000e+00')
Decimal('0E-19')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 02:24:18 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 06:24:18 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507098258.48.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> When optimizing, please don't make API changes.

This is not only optimization, but bugfix.

Document of string.Template says:

> By default, "identifier" is restricted to any case-insensitive ASCII  alphanumeric string (including underscores) that starts with an underscore or ASCII letter.

So, missing re.ASCII flag is bug because non-ASCII alphabet can be matched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 02:29:15 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 06:29:15 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507098555.81.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> Yet one way -- make re.ASCII a local flag. Than we could just change the idpattern attribute to r'(?a:[_a-z][_a-z0-9]*)', without touching the flags attribute.

https://docs.python.org/3.6/library/re.html#regular-expression-syntax says
`(?imsx-imsx:...)`

Anyway, Template.idpattern is documented public API too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 02:37:11 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 06:37:11 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507099031.54.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Current pull request override `Template.flags = re.I` after class creation for backward compatibility, without any API change.

But I'm not sure it's right approach.
How many people who subclass string.Template expect non-ASCII match?
If this change is bugfix for 99% of subclasses, why should we keep pitfall?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 02:40:06 2017
From: report at bugs.python.org (Nitish)
Date: Wed, 04 Oct 2017 06:40:06 +0000
Subject: [issue31557] tarfile: incorrectly treats regular file as directory
In-Reply-To: <1506116521.84.0.445900877205.issue31557@psf.upfronthosting.co.za>
Message-ID: <1507099206.21.0.213398074469.issue31557@psf.upfronthosting.co.za>


Nitish <nitishchandrachinta at gmail.com> added the comment:

Try 'tar xvf test.tar'. On Linux machine at least, it is in fact producing a tree of directories. Not a single file. So - in a way what Python is reporting is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31557>
_______________________________________

From report at bugs.python.org  Wed Oct  4 05:12:44 2017
From: report at bugs.python.org (Safihre)
Date: Wed, 04 Oct 2017 09:12:44 +0000
Subject: [issue1759845] subprocess.call fails with unicode strings in command
 line
Message-ID: <1507108364.11.0.213398074469.issue1759845@psf.upfronthosting.co.za>


Safihre <safihre at sabnzbd.org> added the comment:

Although this issue is very old, in case anyone else like us need this functionality I created a package that implements the proposed C-fix.
https://pypi.python.org/pypi/subprocessww
Simply "import subprocessww" and POpen is patched. We tested it and it does the job pretty well, haven't run into special situations yet.

We really want to upgrade our app to Python 3, but currently lack the manpower to go over our app line by line. It's not a simple 2to3 conversion, unfortunately.

----------
nosy: +Safihre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Wed Oct  4 05:36:35 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 09:36:35 +0000
Subject: [issue31687] test_semaphore_tracker() of test_multiprocessing_spawn
 fails randomly (race condition?)
Message-ID: <1507109795.91.0.213398074469.issue31687@psf.upfronthosting.co.za>


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

Recent example of the slow and busy (load of 8.05 with 2 CPUs) x86 Gentoo Refleaks 3.6 buildbot:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Refleaks%203.6/builds/111/steps/test/logs/stdio

== CPU count: 2
...
1:41:09 load avg: 8.05 [170/405/1] test_multiprocessing_spawn failed -- running: test_asyncio (1118 sec)
beginning 6 repetitions
123456
/buildbot/buildarea/3.6.ware-gentoo-x86.refleak/build/Lib/unittest/case.py:633: ResourceWarning: unclosed file <_io.BufferedReader name=22>
  outcome.errors.clear()
test test_multiprocessing_spawn failed -- Traceback (most recent call last):
  File "/buildbot/buildarea/3.6.ware-gentoo-x86.refleak/build/Lib/test/_test_multiprocessing.py", line 4091, in test_semaphore_tracker
    _multiprocessing.sem_unlink(name2)
AssertionError: OSError not raised
1:41:12 load avg: 7.97 [171/405/1] test_posixpath passed -- running: test_asyncio (1122 sec)
beginning 6 repetitions
123456
......

----------
components: Tests
messages: 303678
nosy: haypo
priority: normal
severity: normal
status: open
title: test_semaphore_tracker() of test_multiprocessing_spawn fails randomly (race condition?)
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31687>
_______________________________________

From report at bugs.python.org  Wed Oct  4 06:00:39 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 10:00:39 +0000
Subject: [issue1759845] [2.7] subprocess.call fails with unicode strings in
 command line
Message-ID: <1507111239.71.0.213398074469.issue1759845@psf.upfronthosting.co.za>


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


----------
title: subprocess.call fails with unicode strings in command line -> [2.7] subprocess.call fails with unicode strings in command line

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1759845>
_______________________________________

From report at bugs.python.org  Wed Oct  4 06:06:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 10:06:26 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507111586.4.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Nice speedup!

I ran a benchmark on PR 3862:

 1002  ./python ~/prog/python/performance/performance/benchmarks/bm_regex_compile.py --inherit=PYTHONPATH -v -o patch.json
 1003  git co master
 1004  make
 1005  ./python ~/prog/python/performance/performance/benchmarks/bm_regex_compile.py --inherit=PYTHONPATH -v -o ref.json
 1007  ./python -m perf compare_to ref.json patch.json 

Mean +- std dev: [ref] 396 ms +- 16 ms -> [patch] 347 ms +- 8 ms: 1.14x faster (-12%)

It's the following benchmark on *uncached* regular expressions. So it really measures re.compile() performance, not the cache.
https://pyperformance.readthedocs.io/benchmarks.html#regex-compile

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 08:08:59 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 Oct 2017 12:08:59 +0000
Subject: [issue30465] FormattedValue expressions have wrong lineno and
 col_offset information
In-Reply-To: <1495666417.53.0.222363680661.issue30465@psf.upfronthosting.co.za>
Message-ID: <1507118939.87.0.213398074469.issue30465@psf.upfronthosting.co.za>


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

I think it's fixed. Closing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30465>
_______________________________________

From report at bugs.python.org  Wed Oct  4 08:33:04 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 12:33:04 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507120384.97.0.213398074469.issue31671@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Thank you for benchmarking.  I've added news entry about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 08:33:34 2017
From: report at bugs.python.org (abdullah patel)
Date: Wed, 04 Oct 2017 12:33:34 +0000
Subject: [issue31688] scope error
Message-ID: <1507120414.78.0.213398074469.issue31688@psf.upfronthosting.co.za>


New submission from abdullah patel <abdullahpatel1189 at gmail.com>:

there should be an error when this code is run. as  I have not defined the arguments (I was told by my computer science teacher that it should not work in theory) and parameters but it clearly works.

----------
assignee: terry.reedy
components: IDLE
files: pythonerror.jpg
messages: 303682
nosy: abdullah patel, terry.reedy
priority: normal
severity: normal
status: open
title: scope error
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47190/pythonerror.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31688>
_______________________________________

From report at bugs.python.org  Wed Oct  4 08:53:19 2017
From: report at bugs.python.org (Allen Riddell)
Date: Wed, 04 Oct 2017 12:53:19 +0000
Subject: [issue31689] random.choices does not work with negative weights
Message-ID: <1507121599.13.0.213398074469.issue31689@psf.upfronthosting.co.za>


New submission from Allen Riddell <abr at ariddell.org>:

Code to reproduce problem:

population = list(range(10))
weights = list(-1 * w for w in range(10))
[random.choices(population, weights) for _ in range(1000)]

will raise IndexError:

    358         bisect = _bisect.bisect
    359         total = cum_weights[-1]
--> 360         return [population[bisect(cum_weights, random() * total)] for i in range(k)]
    361 
    362 ## -------------------- real-valued distributions  -------------------

IndexError: list index out of range

----------
components: Library (Lib)
messages: 303683
nosy: ariddell
priority: normal
severity: normal
status: open
title: random.choices does not work with negative weights
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31689>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:11:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 13:11:15 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507122675.71.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Naoki: "I've added news entry about it."

Nice. You might also mention the "optimization" in What's New in Python 3.7 doc, in the Optimisations section. The issue here is that it's only faster than Python 3.6, but Python 3.6 was slower than 3.5 :-) The "optimization" just makes Python 3.7 as fast as Python 3.5 ... :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:11:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 13:11:23 +0000
Subject: [issue31619] Strange error when convert hexadecimal with underscores
 to int
In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za>
Message-ID: <1507122683.67.0.213398074469.issue31619@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3857

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31619>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:18:50 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Oct 2017 13:18:50 +0000
Subject: [issue31689] random.choices does not work with negative weights
In-Reply-To: <1507121599.13.0.213398074469.issue31689@psf.upfronthosting.co.za>
Message-ID: <1507123130.44.0.213398074469.issue31689@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@ariddell: What behaviour did you want to see here?

It wouldn't have occurred to me to even try using `random.choices` with negative weights; forcing the weights to be nonnegative (with strictly positive sum) sounds like a natural restriction.

----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31689>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:23:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 13:23:32 +0000
Subject: [issue31619] Strange error when convert hexadecimal with underscores
 to int
In-Reply-To: <1506608047.28.0.466225441844.issue31619@psf.upfronthosting.co.za>
Message-ID: <1507123412.47.0.213398074469.issue31619@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I missed the issue mentioned by Mark msg303331. I looked at the type of n, and okay, it is Py_ssize_t. But I forgot to check the type of digits and bits_per_char, and it is int. My fix doesn't guard from integer overflow.

The following PR fixes this. It also tries to guard against integer overflow in other place. Unfortunately there is yet one issue with that code. The guard works on 32-bit platform, where the precision of double is large than the size of Py_size_t. But on 64-bit platform it is possible that (Py_ssize_t)(digits * log_base_BASE[base]) takes the value not enough for writing the result of the parsing, because its lowest bits are lost.

I know that converting str to int with non-binary base has nonlinear complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31619>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:31:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 13:31:42 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507123902.9.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Did you compare the benchmarking results against 3.7 or 3.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:34:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 13:34:34 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507124074.43.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

> Did you compare the benchmarking results against 3.7 or 3.6?

My lasted benchmark is on the master branch: original code ("ref") vs code patched with PR 3862 ("patch").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:42:39 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Oct 2017 13:42:39 +0000
Subject: [issue31688] scope error
In-Reply-To: <1507120414.78.0.213398074469.issue31688@psf.upfronthosting.co.za>
Message-ID: <1507124559.21.0.213398074469.issue31688@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The code looks fine to me; I don't see any reason to expect an error.

What error were you expecting, and why?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31688>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:47:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 13:47:41 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507124861.66.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It makes sense to report the performance gain only in comparison with the previous released version. I expect that re compiling is slower in 3.7 due to new features and optimizations. Generating more optimal code takes a time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:50:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 13:50:59 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507125059.59.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

I don't really care if Python 3.7 is still slower than 3.6 with PR 3862. The speedup is significant, the change is short and safe, so the PR LGTM :-) We can implement further optimizations later ;-)

By the way, speed.python.org can be used to track performances over time. Sadly, I didn't have much time to take care of the website: run manually to job to draw new plots :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 09:57:11 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 13:57:11 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507098555.81.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <ECA16B1F-253E-49E6-AFBD-E12BE724037C@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 4, 2017, at 02:29, INADA Naoki <report at bugs.python.org> wrote:
> 
> INADA Naoki <songofacandy at gmail.com> added the comment:
> 
>> Yet one way -- make re.ASCII a local flag. Than we could just change the idpattern attribute to r'(?a:[_a-z][_a-z0-9]*)', without touching the flags attribute.
> 
> https://docs.python.org/3.6/library/re.html#regular-expression-syntax says
> `(?imsx-imsx:...)`
> 
> Anyway, Template.idpattern is documented public API too.

Too bad, because I like that approach.  How hard would it be to add support for ?a? as a local flag?  (I?m kind of surprised that it isn?t already supported - it seems like it would be useful.)

I would like this better than hacking Template.flags after the fact.  It seems like the right way to align the code with the documentation (i.e. fix a bug).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:02:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 14:02:56 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
Message-ID: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently re supports local inline flags. 'a(?i:b)' matches 'a' cases-sensitively, but 'b' case-insensitively. But flags 'a' and 'L' can't be scoped to a subpattern. The 'u' flag currently just redundant, it doesn't make effect in string patterns, and is not allowed in bytes patterns. They can be applied only to the whole pattern. I think it would be nice to make them local.

The example of the problem that this can solve is issue31672. Currently '[a-z]' in Unicode case-insensitive mode matches not only Latin letters from ;a' to 'z' and from 'A' to 'Z', but also characters '?', '?', '?' and '?' which are equivalent to 'i', 's' and 'k' correspondingly. With local 'a' and 'u' flags you can use ASCII and Unicode ranges in the same pattern.

I'm working on the patch.

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
messages: 303693
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Make RE "a", "L" and "u" inline flags local
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:03:47 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 14:03:47 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1507125827.74.0.213398074469.issue31690@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:05:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 14:05:39 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507125939.64.0.213398074469.issue31672@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See issue31690. But this solution can be used only in 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:07:33 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 14:07:33 +0000
Subject: [issue31677] email.header uses re.IGNORECASE without re.ASCII
In-Reply-To: <1507089113.55.0.213398074469.issue31677@psf.upfronthosting.co.za>
Message-ID: <FF0DCCDD-F18B-48B4-AA7A-396DE742068F@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 3, 2017, at 23:51, INADA Naoki <report at bugs.python.org> wrote:
>> It's better to keep the re.IGNORECASE since the RFC also says:
>> 
>>  Both 'encoding' and 'charset' names are case-independent.  Thus the
>>  charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
>>  encoding named "Q" may be spelled either "Q" or "q".
> 
> I'm sorry, I've committed before reading this.
> But I think it's not problem, because re.IGNORECASE doesn't affect to
> "(?P<charset>[^?]*?)" pattern.

I think you?re change is fine, no need to revert or modify it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31677>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:08:51 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 14:08:51 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507125939.64.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <0768F730-C554-45FF-8250-134F0643E400@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 4, 2017, at 10:05, Serhiy Storchaka <report at bugs.python.org> wrote:
> 
> See issue31690. But this solution can be used only in 3.7.

That?s fine.  I don?t think this is important enough to backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:11:55 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 14:11:55 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1507126315.86.0.213398074469.issue31690@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +3858
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:27:35 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 Oct 2017 14:27:35 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507127255.43.0.213398074469.issue31684@psf.upfronthosting.co.za>


Change by Eric V. Smith <eric at trueblade.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:41:15 2017
From: report at bugs.python.org (Allen Riddell)
Date: Wed, 04 Oct 2017 14:41:15 +0000
Subject: [issue31689] random.choices does not work with negative weights
In-Reply-To: <1507121599.13.0.213398074469.issue31689@psf.upfronthosting.co.za>
Message-ID: <1507128075.36.0.213398074469.issue31689@psf.upfronthosting.co.za>


Allen Riddell <abr at ariddell.org> added the comment:

Upon some reflection, I think raising a ValueError is the right thing to do. Negative weights don't have an obvious interpretation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31689>
_______________________________________

From report at bugs.python.org  Wed Oct  4 10:46:15 2017
From: report at bugs.python.org (Michael Cuthbert)
Date: Wed, 04 Oct 2017 14:46:15 +0000
Subject: [issue17446] doctest test finder doesnt find line numbers of
 properties
In-Reply-To: <1363536507.07.0.43500928967.issue17446@psf.upfronthosting.co.za>
Message-ID: <1507128375.58.0.213398074469.issue17446@psf.upfronthosting.co.za>


Michael Cuthbert <cuthbert at mit.edu> added the comment:

A pull request has been in for about a month -- is it possible to review or merge or comment?  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17446>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:09:59 2017
From: report at bugs.python.org (Ivan Pozdeev)
Date: Wed, 04 Oct 2017 15:09:59 +0000
Subject: [issue31691] Include missing info on required build steps and how to
 build installer
Message-ID: <1507129799.44.0.213398074469.issue31691@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev <ivan_pozdeev at mail.ru>:

Current build instructions no not mention required preliminary steps before building the solution and don't say how to build the installer package - which is the ultimate goal of a build.

Being on XP at the moment, I cannot check the validity of build instructions for other branches. Maybe they can use this info as well.

----------
components: Build
files: 0001-Add-missing-build-steps-in-build-procedure.patch
keywords: patch
messages: 303700
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: Include missing info on required build steps and how to build installer
versions: Python 2.7, Python 3.4
Added file: https://bugs.python.org/file47191/0001-Add-missing-build-steps-in-build-procedure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31691>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:11:16 2017
From: report at bugs.python.org (Ivan Pozdeev)
Date: Wed, 04 Oct 2017 15:11:16 +0000
Subject: [issue31691] Include missing info on required build steps and how to
 build installer
In-Reply-To: <1507129799.44.0.213398074469.issue31691@psf.upfronthosting.co.za>
Message-ID: <1507129876.11.0.213398074469.issue31691@psf.upfronthosting.co.za>


Change by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


Added file: https://bugs.python.org/file47192/0001-Add-missing-build-steps-in-build-procedure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31691>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:13:16 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 15:13:16 +0000
Subject: [issue28805] Add documentation for METH_FASTCALL
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1507129996.17.0.213398074469.issue28805@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This and the _PyObject_FastCall* APIs really do need to be documented, especially if they're going to be used in the interpreter itself.  The leading underscore signifies that it's not part of the public API (well, METH_FASTCALL doesn't have a leading underscore).

When these are not documented, then they aren't discoverable, so there are cases where it may be useful but will be overlooked.  It also means that folks will be inclined to cargo cult the few existing uses without perhaps understanding the full semantics.

Can we please document these for Python 3.7 at least?

----------
nosy: +barry
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28805>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:13:32 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 15:13:32 +0000
Subject: [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1507130012.9.0.213398074469.issue28805@psf.upfronthosting.co.za>


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


----------
title: Add documentation for METH_FASTCALL -> Add documentation for METH_FASTCALL and _PyObject_FastCall*()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28805>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:16:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 15:16:57 +0000
Subject: [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1507130217.82.0.213398074469.issue28805@psf.upfronthosting.co.za>


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

> Can we please document these for Python 3.7 at least?

I chose to not document FASTCALL on purpose in Python 3.6, I wanted to keep everything private, until we get enough feedback and stabilize the API.

Recently, the FASTCALL API changed: METH_FASTCALL doesn't support keywords anymore. You have to pass METH_FASTCALL|METH_KEYWORDS.

It seems like the API became stable.

I don't know if we should make the API public or not. PyPy would complain as usual that we give them more work to do :-D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28805>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:18:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 15:18:55 +0000
Subject: [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1507130335.27.0.213398074469.issue28805@psf.upfronthosting.co.za>


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

I suggest to document the following 4 functions/macros:

PyAPI_FUNC(PyObject *) _PyObject_FastCallDict(
    PyObject *callable,
    PyObject **args,
    Py_ssize_t nargs,
    PyObject *kwargs);

PyAPI_FUNC(PyObject *) _PyObject_FastCallKeywords(
    PyObject *callable,
    PyObject **args,
    Py_ssize_t nargs,
    PyObject *kwnames);

#define _PyObject_FastCall(func, args, nargs) \
    _PyObject_FastCallDict((func), (args), (nargs), NULL)

#define _PyObject_CallNoArg(func) \
    _PyObject_FastCallDict((func), NULL, 0, NULL)

And the METH_FASTCALL and METH_FASTCALL|METH_KEYWORDS calling convention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28805>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:19:37 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 15:19:37 +0000
Subject: [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1507130377.41.0.213398074469.issue28805@psf.upfronthosting.co.za>


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

> It would also be nice if Cython could use it automatically.

Cython is using FASTCALL since Python 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28805>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:42:48 2017
From: report at bugs.python.org (Iryna Shcherbina)
Date: Wed, 04 Oct 2017 15:42:48 +0000
Subject: [issue31692] Test `test_huntrleaks` fails in debug build with
 COUNT_ALLOCS
Message-ID: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>


New submission from Iryna Shcherbina <shcherbina.iryna at gmail.com>:

The newly added `test_huntrleaks` test is failing on Python 2.7.14 debug build with COUNT_ALLOCS.


======================================================================
FAIL: test_huntrleaks (test.test_regrtest.ArgsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-2.7.14/Lib/test/test_regrtest.py", line 511, in test_huntrleaks
    self.check_leak(code, 'references')
  File "/builddir/build/BUILD/Python-2.7.14/Lib/test/test_regrtest.py", line 489, in check_leak
    self.assertIn(line2, output)
AssertionError: 'test_regrtest_huntrleaks leaked [1, 1, 1] references, sum=3\n' not found in 'Run tests sequentially\n0:00:00 load avg: 0.63 [1/1] test_regrtest_huntrleaks\nbeginning 6 repetitions\n123456\n......\ntest_regrtest_huntrleaks leaked [93, 93, 93] references, sum=279\n1 test failed:\n    test_regrtest_huntrleaks\n\nTotal duration: 32 ms\nTests result: FAILURE\n[53092 refs]\n'
----------------------------------------------------------------------


On Python 2.7.14 debug build *without* COUNT_ALLOCS the test passes fine, therefore I am not sure if there is a leak detected, or is it just COUNT_ALLOCS messing with the test and it should be skipped.

----------
components: Tests
messages: 303705
nosy: ishcherb
priority: normal
severity: normal
status: open
title: Test `test_huntrleaks` fails in debug build with COUNT_ALLOCS
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Wed Oct  4 11:52:33 2017
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Oct 2017 15:52:33 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507132353.01.0.213398074469.issue31671@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

IntFlag.__and__ does not create a new instance every time -- all new instances are cached in the IntFlag machinery (so RegexFlag(7) is only created once).

If all the RegexFlag combinations are created before the regex compile benchmark do we still see a speed-up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:02:55 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Oct 2017 16:02:55 +0000
Subject: [issue31693] Document Py_GETENV
Message-ID: <1507132975.16.0.213398074469.issue31693@psf.upfronthosting.co.za>


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

I already added a section to the C API docs for some useful macros.  I didn't know about this one when I did that, but it seems like a useful macro to document, so I will do that.

----------
assignee: barry
components: Documentation
messages: 303707
nosy: barry
priority: normal
severity: normal
status: open
title: Document Py_GETENV
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31693>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:19:08 2017
From: report at bugs.python.org (Ivan Pozdeev)
Date: Wed, 04 Oct 2017 16:19:08 +0000
Subject: [issue31623] Allow to build MSI installer from the official tarball
In-Reply-To: <1507066385.94.0.213398074469.issue31623@psf.upfronthosting.co.za>
Message-ID: <b1c4845c-bb1f-c69b-e06e-89af4fd75d00@mail.ru>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

> Note, though, that you are likely to be the only person on Earth 
using this installer, since there will be no more binary releases of 3.4

Since this is the last release for XP, probably the ppl who are stuck on 
this OS as well. An installable package is a must for any 
maintainability to speak of. The lack of a binary release is actually 
going to be a boost for its use, here :-)

I also had trouble discovering this script in the first place since it's 
not mentioned in PCBuild/readme.txt .
If build instructions are updated as per issue31691 , this would help 
potential users as well.

Beside this patch, issue31170 and issue31645 are needed for the 3.4 
build to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31623>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:37:05 2017
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 04 Oct 2017 16:37:05 +0000
Subject: [issue31623] Allow to build MSI installer from the official tarball
In-Reply-To: <1506646876.94.0.213398074469.issue31623@psf.upfronthosting.co.za>
Message-ID: <1507135025.07.0.213398074469.issue31623@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

If you're still on XP, security is obviously not a big concern and you're just as well off to stick with 3.4.4 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31623>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:38:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 16:38:23 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1507135103.89.0.213398074469.issue31690@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3860

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:48:23 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Oct 2017 16:48:23 +0000
Subject: [issue31688] scope error
In-Reply-To: <1507120414.78.0.213398074469.issue31688@psf.upfronthosting.co.za>
Message-ID: <1507135703.74.0.213398074469.issue31688@psf.upfronthosting.co.za>


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

Yes, this conforms to Python's namespace/scoping rules: nested scopes are allowed to reference (but not assign to) variables from the global scope even without a 'global' declaration.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31688>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:50:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Oct 2017 16:50:14 +0000
Subject: [issue31683] a stack overflow on windows in
 faulthandler._fatal_error()
In-Reply-To: <1507066812.21.0.213398074469.issue31683@psf.upfronthosting.co.za>
Message-ID: <1507135814.31.0.213398074469.issue31683@psf.upfronthosting.co.za>


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


New changeset 8d5a3aad2f805dc0ea40829b751f58aa6c75305d by Victor Stinner in branch 'master':
bpo-31683: Py_FatalError() now supports long error messages (#3878)
https://github.com/python/cpython/commit/8d5a3aad2f805dc0ea40829b751f58aa6c75305d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31683>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:54:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 16:54:06 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1507136046.01.0.213398074469.issue31690@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 3885 is a preliminary but working implementation. Needed new tests and documentation.

>>> import re
>>> re.findall('(?i:[a-z]+)', ''.join(map(chr, range(0x10000))))
['ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz', '??', '?', '?']
>>> re.findall('(?ia:[a-z]+)', ''.join(map(chr, range(0x10000))))
['ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz']

The engine now uses separate opcodes for case-insensitive matching in ASCII, UNICODE and LOCALE modes. It may cause small speed up of matching, but slow down of compiling.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Wed Oct  4 12:54:07 2017
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Oct 2017 16:54:07 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507136047.48.0.213398074469.issue31676@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The whole imp module is deprecated so I'm personally not bothered by imp.load_source() not being strengthened to be more sane.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:09:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 17:09:51 +0000
Subject: [issue30397] Expose regular expression and match objects types in the
 re module
In-Reply-To: <1495099071.76.0.78537158998.issue30397@psf.upfronthosting.co.za>
Message-ID: <1507136991.24.0.213398074469.issue30397@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0b5e61ddca73ad4fe597fb15065115b0285c8849 by Serhiy Storchaka in branch 'master':
bpo-30397: Add re.Pattern and re.Match. (#1646)
https://github.com/python/cpython/commit/0b5e61ddca73ad4fe597fb15065115b0285c8849


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30397>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:19:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 17:19:41 +0000
Subject: [issue30397] Expose regular expression and match objects types in the
 re module
In-Reply-To: <1495099071.76.0.78537158998.issue30397@psf.upfronthosting.co.za>
Message-ID: <1507137581.91.0.213398074469.issue30397@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30397>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:21:19 2017
From: report at bugs.python.org (Joe Tsai)
Date: Wed, 04 Oct 2017 17:21:19 +0000
Subject: [issue31557] tarfile: incorrectly treats regular file as directory
In-Reply-To: <1506116521.84.0.445900877205.issue31557@psf.upfronthosting.co.za>
Message-ID: <1507137679.91.0.213398074469.issue31557@psf.upfronthosting.co.za>


Joe Tsai <joetsai at google.com> added the comment:

It creates a number of nested directories only because GNU (and BSD) tar implicitly create missing parent directories. If you cd into the bottom-most folder, you will see "foo.txt".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31557>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:24:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 17:24:42 +0000
Subject: [issue30404] Make stdout and stderr truly unbuffered when using -u
 option
In-Reply-To: <1495209125.34.0.468493818937.issue30404@psf.upfronthosting.co.za>
Message-ID: <1507137882.39.0.213398074469.issue30404@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If there is a need in making redirected stdout line-buffered, a new option can be added in separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30404>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:25:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 17:25:42 +0000
Subject: [issue30404] Make stdout and stderr truly unbuffered when using -u
 option
In-Reply-To: <1495209125.34.0.468493818937.issue30404@psf.upfronthosting.co.za>
Message-ID: <1507137942.8.0.213398074469.issue30404@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 77732be801c18013cfbc86e27fcc50194ca22c8e by Serhiy Storchaka in branch 'master':
bpo-30404: The -u option now makes the stdout and stderr streams totally unbuffered. (#1667)
https://github.com/python/cpython/commit/77732be801c18013cfbc86e27fcc50194ca22c8e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30404>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:26:10 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 17:26:10 +0000
Subject: [issue30404] Make stdout and stderr truly unbuffered when using -u
 option
In-Reply-To: <1495209125.34.0.468493818937.issue30404@psf.upfronthosting.co.za>
Message-ID: <1507137970.45.0.213398074469.issue30404@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30404>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:28:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 17:28:23 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1507138103.18.0.213398074469.issue31667@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c02a1f4ad8fcdbffad2911c5a31c71a17a89d713 by Serhiy Storchaka in branch 'master':
bpo-31667: Fix gettext related links. (#3860)
https://github.com/python/cpython/commit/c02a1f4ad8fcdbffad2911c5a31c71a17a89d713


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:29:36 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Oct 2017 17:29:36 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1507138176.17.0.213398074469.issue31667@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3861

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:40:01 2017
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 04 Oct 2017 17:40:01 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507138801.98.0.213398074469.issue31684@psf.upfronthosting.co.za>


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

Yes, from the point of view of decimal it's the right thing:

>>> x = Decimal("1e25").quantize(Decimal("1e30"))
>>> x
Decimal('0E+30')
>>> '{:+.19e}'.format(x)
'+0.0000000000000000000e+49'
>>> 

The original magnitude should be traceable (the example is not
perfect but the first thing that quickly came to mind).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:44:30 2017
From: report at bugs.python.org (Aaron Meurer)
Date: Wed, 04 Oct 2017 17:44:30 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507139070.39.0.213398074469.issue31684@psf.upfronthosting.co.za>


Aaron Meurer <asmeurer at gmail.com> added the comment:

I guess I would expect that to be captured by the number of zeros printed (and obviously doing a string format operation with a set number of digits destroys that information).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 13:48:23 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 Oct 2017 17:48:23 +0000
Subject: [issue31688] scope error
In-Reply-To: <1507120414.78.0.213398074469.issue31688@psf.upfronthosting.co.za>
Message-ID: <1507139303.51.0.213398074469.issue31688@psf.upfronthosting.co.za>


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

Abdullah, in the future, please upload or post runnable Python code, not an image.  Output can be copied into a message.  If you think IDLE is doing something wrong, test by running the code directly with Python.  If your file is test.py, enter the following on a Command Prompt command line.
path-to-your-python-code-dir> python -m test.py

There would only be an IDLE issue (and then only maybe) if the code ran differently or produced different output in IDLE than with python directly.  That is not the case here.

----------
assignee: terry.reedy -> 
components: +Interpreter Core -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31688>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:06:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 18:06:12 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1507140372.51.0.213398074469.issue31667@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ed77fbffa5bf81c8d16700370fe8bb63bbae1428 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31667: Fix gettext related links. (GH-3860) (#3886)
https://github.com/python/cpython/commit/ed77fbffa5bf81c8d16700370fe8bb63bbae1428


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:11:11 2017
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 04 Oct 2017 18:11:11 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507140671.07.0.213398074469.issue31684@psf.upfronthosting.co.za>


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

I don't think format() destroys the information:

>>> '{:+.19e}'.format(Decimal("0.00000e20"))
'+0.0000000000000000000e+34'


The original magnitude was e+15, after formatting it's still e+15.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:25:01 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 04 Oct 2017 18:25:01 +0000
Subject: [issue31657] unit test for optimization levels does not cover
 __debug__ case
In-Reply-To: <1506870513.15.0.213398074469.issue31657@psf.upfronthosting.co.za>
Message-ID: <1507141501.68.0.213398074469.issue31657@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks for this enhancement, Diana.

Since PR has been merged, and backport is not needed, I think this can be closed now. :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31657>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:36:14 2017
From: report at bugs.python.org (Aaron Meurer)
Date: Wed, 04 Oct 2017 18:36:14 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507142174.41.0.213398074469.issue31684@psf.upfronthosting.co.za>


Aaron Meurer <asmeurer at gmail.com> added the comment:

I meant that format() destroys information in a decimal in general. Obviously if you have n digits of precision and format with m < n, then you lose information. 

I also can't help but feel that we're mixing up "trailing zeros" (i.e., precision), and "exponent" (magnitude), which should be orthogonal. I'm assuming that a decimal is represented internally as base*10**exponent. I'm also assuming that Decimal(0) sets both base and exponent to 0. It doesn't make sense to me that a string formatting operation that requests a certain number of digits of precision should change the exponent. 

I get that 0.0 is different from 0.00000, but in that case, they should print differently: as '0.0' and '0.00000'. It seems sly to try to maintain that through a format operation via the exponent, especially when format *in general* loses precision information for a decimal anyway (by "format" I mean format with a set number of digits requested). Especially since that "trick" only works for exactly one number, zero. If you do '{:+.30e}'.format(Decimal('1.0000000000000000000')) or '{:+.10e}'.format(Decimal('1.0000000000000000000')), no such trick is used, because no such trick can be used. You just lose information. 

I'm sure my mental model is off here. I'm used to sympy.Float/mpmath.mpf where values like 0*2**i are normalized to i = 0 (e.g. mpmath.mpf((0, 0, 20, 0))._mpf_ gives (0, 0, 0, 0)), so this problem never comes up in the code that I'm used to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:37:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 18:37:55 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507142275.99.0.213398074469.issue31675@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 328b5d0e64798cf17360c6b2a07c2b18f2798b88 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-31675: Fix memory leaks in Tkinter's methods splitlist() and split() (GH-3866) (#3876)
https://github.com/python/cpython/commit/328b5d0e64798cf17360c6b2a07c2b18f2798b88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:52:39 2017
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 04 Oct 2017 18:52:39 +0000
Subject: [issue31694] Running Windows installer with LauncherOnly=1 should not
 register the version as installed
Message-ID: <1507143159.66.0.213398074469.issue31694@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

After running

    python-3.6.2-amd64.exe /quiet LauncherOnly=1

Python 3.6.2 is registered as installed, even though nothing is actually installed.

Running the installer again at this point shows an error indicating ?this product is already installed?, and does not show me the usual repair/modify/uninstall options.

I have to run uninstallation with Control Panel before the installer works again.

----------
components: Installation
messages: 303727
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Running Windows installer with LauncherOnly=1 should not register the version as installed
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31694>
_______________________________________

From report at bugs.python.org  Wed Oct  4 14:56:48 2017
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 04 Oct 2017 18:56:48 +0000
Subject: [issue31694] Running Windows installer with LauncherOnly=1 should not
 register the version as installed
In-Reply-To: <1507143159.66.0.213398074469.issue31694@psf.upfronthosting.co.za>
Message-ID: <1507143408.4.0.213398074469.issue31694@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> steve.dower
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31694>
_______________________________________

From report at bugs.python.org  Wed Oct  4 15:02:15 2017
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 04 Oct 2017 19:02:15 +0000
Subject: [issue31684] Scientific formatting of decimal 0 different from float 0
In-Reply-To: <1507067181.62.0.213398074469.issue31684@psf.upfronthosting.co.za>
Message-ID: <1507143735.71.0.213398074469.issue31684@psf.upfronthosting.co.za>


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

> I'm also assuming that Decimal(0) sets both base and exponent to 0.

No, 0 is really special in the IBM specification. The magnitude is
kept, the precision is not.

>>> Decimal("0e10") * Decimal("0e20") 
Decimal('0E+30')


>>> Decimal("0.000e10")
Decimal('0E+7')

So we're basically doing the reverse of the above in formatting when a
precision is given.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31684>
_______________________________________

From report at bugs.python.org  Wed Oct  4 15:02:26 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 19:02:26 +0000
Subject: [issue31675] Tkinter: memory leak in splitlines() and split()
In-Reply-To: <1507032263.31.0.213398074469.issue31675@psf.upfronthosting.co.za>
Message-ID: <1507143746.57.0.213398074469.issue31675@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31675>
_______________________________________

From report at bugs.python.org  Wed Oct  4 15:22:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 19:22:19 +0000
Subject: [issue31695] Improve bigmem tests
Message-ID: <1507144939.6.0.213398074469.issue31695@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

I think that the process of running bigmem tests should be improved.

1. Every bigmem test should run in separate process. It's effect on memory fragmentation shouldn't affect other tests.

2. Only one bigmem test should be run at the same time. Otherwise several parallel bigmem tests  can exhaust RAM and lead to swapping. In multiprocessing mode the process running a bigmem test should send a signal to other processes, wait until they finished their current tests and paused, run a bigmem test, and send a signal to other processes that they can continue.

3. The hard limit of addressed memory should be set for every bigmem test, according to the declared requirements. It is better to crash one test and report the failure, than hang on swapping.

4. All other tests should be run with the limit set to 2 GiB (or 1 GiB?). This will help to find memory consuming tests which should be made bigmem tests.

5. The maxrss of the process running a bigmem test should be reported in verbose mode after finishing a test.

----------
components: Tests
messages: 303729
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve bigmem tests
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31695>
_______________________________________

From report at bugs.python.org  Wed Oct  4 15:44:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 19:44:19 +0000
Subject: [issue30872] Update curses docs to Python 3
In-Reply-To: <1499440453.75.0.308646182968.issue30872@psf.upfronthosting.co.za>
Message-ID: <1507146259.94.0.213398074469.issue30872@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 300dd552b15825abfe0e367ac14cec4c3e050dbc by Serhiy Storchaka in branch 'master':
bpo-30872: Update the curses docs to Python 3. (#2620)
https://github.com/python/cpython/commit/300dd552b15825abfe0e367ac14cec4c3e050dbc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30872>
_______________________________________

From report at bugs.python.org  Wed Oct  4 15:45:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Oct 2017 19:45:54 +0000
Subject: [issue30872] Update curses docs to Python 3
In-Reply-To: <1499440453.75.0.308646182968.issue30872@psf.upfronthosting.co.za>
Message-ID: <1507146353.99.0.213398074469.issue30872@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3862

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30872>
_______________________________________

From report at bugs.python.org  Wed Oct  4 16:56:25 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 04 Oct 2017 20:56:25 +0000
Subject: [issue31696] don't mention GCC in sys.version when built with Clang
Message-ID: <1507150585.16.0.213398074469.issue31696@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

When built with clang, Python reports that it was built with something like "GCC 4.2.1 Compatible Clang 4.0.0 (tags/RELEASE_400/rc1)". This is because clang pretends to be GCC 4.2.1 for the purposes of the __VERSION__ preprocessor macro. We should use __clang_version__ when clang is being used.

(Possibly we should simply use the first line of "$CC --version" as the compiler version of record rather than writing preprocessor tests in getcompiler.c.)

----------
components: Build
keywords: easy (C)
messages: 303731
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: don't mention GCC in sys.version when built with Clang
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31696>
_______________________________________

From report at bugs.python.org  Wed Oct  4 18:37:31 2017
From: report at bugs.python.org (Matthew Patton)
Date: Wed, 04 Oct 2017 22:37:31 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507156651.92.0.213398074469.issue30767@psf.upfronthosting.co.za>


Change by Matthew Patton <pattonme at yahoo.com>:


----------
keywords: +patch
pull_requests: +3863
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Wed Oct  4 19:12:30 2017
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 04 Oct 2017 23:12:30 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507158750.55.0.213398074469.issue31671@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> IntFlag.__and__ does not create a new instance every time -- all new instances are cached in the IntFlag machinery (so RegexFlag(7) is only created once).

I'm sorry, I misunderstood.
But while new instance is not created each time, 4 Python method calls
(e,g.  IntFlag.__and__() -> IntFlag.__new__() -> IntFlag._missing_() -> IntFlag._create_pseudo_member_()) are much slower than int & int.

> If all the RegexFlag combinations are created before the regex compile benchmark do we still see a speed-up?

I believe that's what Victor benchmarked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 19:47:30 2017
From: report at bugs.python.org (coady)
Date: Wed, 04 Oct 2017 23:47:30 +0000
Subject: [issue31697] Regression in futures.as_completed with
 ProcessPoolExecutor.
Message-ID: <1507160850.08.0.213398074469.issue31697@psf.upfronthosting.co.za>


New submission from coady <coady at bent-arrow.com>:

`futures.as_completed` is not generating process-based futures in completed order.  Reproduces with 3.7a0.

----------
files: test.py
messages: 303733
nosy: coady
priority: normal
severity: normal
status: open
title: Regression in futures.as_completed with ProcessPoolExecutor.
versions: Python 3.7
Added file: https://bugs.python.org/file47193/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31697>
_______________________________________

From report at bugs.python.org  Wed Oct  4 20:21:47 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Oct 2017 00:21:47 +0000
Subject: [issue31634] Consider installing wheel in ensurepip by default
In-Reply-To: <1506677010.8.0.213398074469.issue31634@psf.upfronthosting.co.za>
Message-ID: <1507162907.27.0.213398074469.issue31634@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Of the listed benefits, I think the most interesting one is the fact it would enable pip's wheel cache by default for all installations, rather than relying on projects publishing pre-built wheel files to PyPI.

However, actually doing this would run counter to the design goal of declaring even the current installation of setuptools to be an implementation details that shouldn't be relied on: https://www.python.org/dev/peps/pep-0453/#automatic-installation-of-setuptools

This relates to the fact that in PyPA, we're aiming to reach a point where we treat setuptools & wheel as *optional* dependencies of pip, such that it's straightforward to create environments that only support installation of wheel files created elsewhere, and don't allow installations directly from source archives at all.

The recently approved PEP 517 represented a notable step in that direction.

That said, we're also discussing the possibility of changing the way we provide distutils to be dependent on automatic installation of setuptools [1], and if we *did* decide to go down that path, then I think it would be appropriate to consider installing both setuptools *and* wheel as part of an "ensuresetuptools" module, rather than just installing setuptools.

Accordingly, while I *am* going to close this (and the related PR), I'm going to close it as "postponed" rather than "rejected" - it isn't that we're definitely never going to do this, it's that there are other long term design considerations involved, and doing this prematurely has the potential to lock us out of design paths that we'd like to keep open.

[1] https://mail.python.org/pipermail/distutils-sig/2017-September/031540.html

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31634>
_______________________________________

From report at bugs.python.org  Wed Oct  4 20:35:27 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Oct 2017 00:35:27 +0000
Subject: [issue31634] Consider installing wheel in ensurepip by default
In-Reply-To: <1506677010.8.0.213398074469.issue31634@psf.upfronthosting.co.za>
Message-ID: <1507163727.85.0.213398074469.issue31634@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As a shorter version of the above:

* the current install time bundling of setuptools in `ensurepip` is likely to be replaced by `pip` dynamically installing both `setuptools` & `wheel` when asked to build from a source archive when no other build system has been specified. With PEP 517 approved, it's entirely plausible that this will happen as part of the `pip 10.0.0` release. So we *won't* be bundling wheel as part of ensurepip, since doing so would conflict with the plan to unbundle setuptools.

* however, we *may* still end up bundling wheel with CPython at some point, *if* we decide to eliminate Lib/distutils entirely in favour of bundling setuptools & wheel.

So it isn't that bundling wheel is entirely out of the question - it's just not something we want to do as part of ensure*pip* specifically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31634>
_______________________________________

From report at bugs.python.org  Wed Oct  4 20:43:48 2017
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 05 Oct 2017 00:43:48 +0000
Subject: [issue31634] Consider installing wheel in ensurepip by default
In-Reply-To: <1506677010.8.0.213398074469.issue31634@psf.upfronthosting.co.za>
Message-ID: <1507164228.83.0.213398074469.issue31634@psf.upfronthosting.co.za>


Donald Stufft <donald at stufft.io> added the comment:

> * the current install time bundling of setuptools in `ensurepip` is likely to be replaced by `pip` dynamically installing both `setuptools` & `wheel` when asked to build from a source archive when no other build system has been specified. With PEP 517 approved, it's entirely plausible that this will happen as part of the `pip 10.0.0` release. So we *won't* be bundling wheel as part of ensurepip, since doing so would conflict with the plan to unbundle setuptools.

Actually PEP 518 provides the mechanism we need for this, and it's already implemented in pip's master branch (what will become pip 10). I don't remember off the top of my head if that covers 100% of the cases yet, but if it doesn't that's just a SMOP. It's entirely plausible that Python 3.7 ships without setuptools included in ensurepip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31634>
_______________________________________

From report at bugs.python.org  Wed Oct  4 21:06:36 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 01:06:36 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507158750.55.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZccABC22qmzYeXuu8Cm2eRtxW=baSKMvHf1Vbg7SD2pA@mail.gmail.com>


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

The perf module always starts with a "warmup" run to fill caches. If enum
has a cache, it should be filled automatically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Wed Oct  4 23:46:44 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 05 Oct 2017 03:46:44 +0000
Subject: [issue31693] Document Py_GETENV
In-Reply-To: <1507132975.16.0.213398074469.issue31693@psf.upfronthosting.co.za>
Message-ID: <1507175204.26.0.213398074469.issue31693@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3864
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31693>
_______________________________________

From report at bugs.python.org  Thu Oct  5 00:09:39 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Oct 2017 04:09:39 +0000
Subject: [issue31689] random.choices does not work with negative weights
In-Reply-To: <1507121599.13.0.213398074469.issue31689@psf.upfronthosting.co.za>
Message-ID: <1507176579.51.0.213398074469.issue31689@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm content with the current exception.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31689>
_______________________________________

From report at bugs.python.org  Thu Oct  5 00:11:29 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Oct 2017 04:11:29 +0000
Subject: [issue31689] random.choices does not work with negative weights
In-Reply-To: <1507121599.13.0.213398074469.issue31689@psf.upfronthosting.co.za>
Message-ID: <1507176689.44.0.213398074469.issue31689@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31689>
_______________________________________

From report at bugs.python.org  Thu Oct  5 00:28:25 2017
From: report at bugs.python.org (Jelle Zijlstra)
Date: Thu, 05 Oct 2017 04:28:25 +0000
Subject: [issue31698] Add REQ_NAME to the node.h API
Message-ID: <1507177705.75.0.213398074469.issue31698@psf.upfronthosting.co.za>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

See https://github.com/python/cpython/pull/1669#pullrequestreview-67229284

----------
assignee: Jelle Zijlstra
components: Interpreter Core
messages: 303739
nosy: Jelle Zijlstra, yselivanov
priority: low
severity: normal
status: open
title: Add REQ_NAME to the node.h API
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31698>
_______________________________________

From report at bugs.python.org  Thu Oct  5 00:44:41 2017
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Oct 2017 04:44:41 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507178681.86.0.213398074469.issue31671@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

INADA Naoki said:
> But while new instance is not created each time, 4 Python method
> calls (e,g.  IntFlag.__and__() -> IntFlag.__new__()
> -> IntFlag._missing_() -> IntFlag._create_pseudo_member_())
> are much slower than int & int.

Only the first two calls always happen -- the last two calls only happen for numbers that haven't been seen yet.  And yes, two Python level calls are much slower than an int & int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 02:35:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 06:35:51 +0000
Subject: [issue30872] Update curses docs to Python 3
In-Reply-To: <1499440453.75.0.308646182968.issue30872@psf.upfronthosting.co.za>
Message-ID: <1507185351.4.0.213398074469.issue30872@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset de5427a8f7ce15565d13383bc8d279bb07dda1cb by Serhiy Storchaka in branch '3.6':
[3.6] bpo-30872: Update the curses docs to Python 3. (GH-2620) (#3887)
https://github.com/python/cpython/commit/de5427a8f7ce15565d13383bc8d279bb07dda1cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30872>
_______________________________________

From report at bugs.python.org  Thu Oct  5 02:37:25 2017
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 05 Oct 2017 06:37:25 +0000
Subject: [issue31694] Running Windows installer with LauncherOnly=1 should not
 register the version as installed
In-Reply-To: <1507143159.66.0.213398074469.issue31694@psf.upfronthosting.co.za>
Message-ID: <1507185445.01.0.213398074469.issue31694@psf.upfronthosting.co.za>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

The ?this product is already installed? error is a mistake on my part. I was actually using 3.6.3 (released literally during I was testing this!) to install the launcher, and using 3.6.2 afterwards, hence the error message (because I was trying to modify using an older version).

The main issue however stays. The installer still shouldn?t register the main Python distribution as installed when only the launcher was selected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31694>
_______________________________________

From report at bugs.python.org  Thu Oct  5 02:41:52 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Oct 2017 06:41:52 +0000
Subject: [issue31696] don't mention GCC in sys.version when built with Clang
In-Reply-To: <1507150585.16.0.213398074469.issue31696@psf.upfronthosting.co.za>
Message-ID: <1507185712.14.0.213398074469.issue31696@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +3865
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31696>
_______________________________________

From report at bugs.python.org  Thu Oct  5 03:01:58 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Oct 2017 07:01:58 +0000
Subject: [issue31596] expose pthread_getcpuclockid in time module
In-Reply-To: <1506450794.16.0.162056328414.issue31596@psf.upfronthosting.co.za>
Message-ID: <1507186918.4.0.213398074469.issue31596@psf.upfronthosting.co.za>


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


New changeset e14679c78464d1e0e16786c2a0e9bcebe49e842b by Benjamin Peterson (pdox) in branch 'master':
closes bpo-31596: Add an interface for pthread_getcpuclockid(3) (#3756)
https://github.com/python/cpython/commit/e14679c78464d1e0e16786c2a0e9bcebe49e842b


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31596>
_______________________________________

From report at bugs.python.org  Thu Oct  5 03:10:11 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Oct 2017 07:10:11 +0000
Subject: [issue27494] 2to3 parser failure caused by a comma after a generator
 expression
In-Reply-To: <1468319353.83.0.357995670089.issue27494@psf.upfronthosting.co.za>
Message-ID: <1507187411.55.0.213398074469.issue27494@psf.upfronthosting.co.za>


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


New changeset af810b35b494ef1d255d4bf340b92a9dad446995 by Benjamin Peterson (Jakub Stasiak) in branch 'master':
closes bpo-27494: Fix 2to3 handling of trailing comma after a generator expression (#3771)
https://github.com/python/cpython/commit/af810b35b494ef1d255d4bf340b92a9dad446995


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27494>
_______________________________________

From report at bugs.python.org  Thu Oct  5 03:27:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 07:27:48 +0000
Subject: [issue30872] Update curses docs to Python 3
In-Reply-To: <1499440453.75.0.308646182968.issue30872@psf.upfronthosting.co.za>
Message-ID: <1507188468.66.0.213398074469.issue30872@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30872>
_______________________________________

From report at bugs.python.org  Thu Oct  5 03:41:45 2017
From: report at bugs.python.org (Thomas Moreau)
Date: Thu, 05 Oct 2017 07:41:45 +0000
Subject: [issue31699] Deadlocks in `concurrent.futures.ProcessPoolExecutor`
 with pickling error
Message-ID: <1507189305.87.0.213398074469.issue31699@psf.upfronthosting.co.za>


New submission from Thomas Moreau <thomas.moreau.2010 at gmail.com>:

When using `concurrent.futures.ProcessPoolExecutor` with objects that are not picklable or unpicklable, several situations results in a deadlock, with the interpreter freezed.

This is the case for different scenario, for instance these three : https://gist.github.com/tomMoral/cc27a938d669edcf0286c57516942369

The different pickling/unpickling error and their effect should be tested in `test_concurrent_futures.py`

----------
components: Library (Lib)
messages: 303745
nosy: tomMoral
priority: normal
pull_requests: 3866
severity: normal
status: open
title: Deadlocks in `concurrent.futures.ProcessPoolExecutor` with pickling error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31699>
_______________________________________

From report at bugs.python.org  Thu Oct  5 03:47:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 07:47:40 +0000
Subject: [issue27169] __debug__ is not optimized out at compile time for
 anything but `if:` and `while:` blocks
In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za>
Message-ID: <1507189660.88.0.213398074469.issue27169@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27169>
_______________________________________

From report at bugs.python.org  Thu Oct  5 03:48:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 07:48:41 +0000
Subject: [issue27169] __debug__ is not optimized out at compile time for
 anything but `if:` and `while:` blocks
In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za>
Message-ID: <1507189721.37.0.213398074469.issue27169@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Build-out an AST optimizer, moving some functionality out of the peephole optimizer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27169>
_______________________________________

From report at bugs.python.org  Thu Oct  5 04:19:32 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 05 Oct 2017 08:19:32 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507191572.45.0.213398074469.issue31671@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset c1c47c166b1012d34f2c6e111ee9ccb5c4d12de7 by INADA Naoki in branch 'master':
bpo-31671: re: Convert RegexFlag to int before compile (GH-3862)
https://github.com/python/cpython/commit/c1c47c166b1012d34f2c6e111ee9ccb5c4d12de7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 04:20:18 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 05 Oct 2017 08:20:18 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507191618.81.0.213398074469.issue31671@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 04:34:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 08:34:31 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507192471.97.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks Naoki!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 04:34:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 08:34:51 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507192491.09.0.213398074469.issue31671@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 04:35:17 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Thu, 05 Oct 2017 08:35:17 +0000
Subject: [issue31700] one-argument version for Generator.typing
Message-ID: <1507192517.86.0.213398074469.issue31700@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at rittau.biz>:

Currently typing.Generator requires three arguments: Generator[YieldType, SendType, ReturnType].

At least for me, passing values to a generator is a very rare case. I suggest to allow only one argument to be passed to Generator: Generator[YieldType], where the other arguments default to None. This makes the common case more readable and is less error-prone. (I always forget the second and third argument, since that use case is so uncommon for me.)

----------
messages: 303748
nosy: srittau
priority: normal
severity: normal
status: open
title: one-argument version for Generator.typing
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31700>
_______________________________________

From report at bugs.python.org  Thu Oct  5 05:29:44 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 09:29:44 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507195784.24.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

My PR 3867 fixes a corner case when the re.compile() is misused ("on purpose"?). I'm going to reject (abandon) my own PR since it makes re.compile() slower:

Mean +- std dev: [ref] 364 ns +- 6 ns -> [patch] 459 ns +- 10 ns: 1.26x slower (+26%)

@Serhiy, @Naoki: Are you ok to reject this PR and keep the corner case bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 05:34:15 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 05 Oct 2017 09:34:15 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507196055.29.0.213398074469.issue31671@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Instead caching type(flags), how about this?

  if not isinstance(flags, int):
      raise TypeError(f"flags must be int or RegexFlag, got {flags!r}")
  flags = int(flags)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 05:59:11 2017
From: report at bugs.python.org (Fynn Be)
Date: Thu, 05 Oct 2017 09:59:11 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
Message-ID: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>


New submission from Fynn Be <thefynnbe at gmail.com>:

c++ extension compiled with MSVC 14
using python 3.6.2 on Windows 10 x64

Whenever a C++ exception is thrown in an extension the faulthandler dumps a traceback to it, even if it is caught.

----------
components: Windows
messages: 303751
nosy: Fynn Be, haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: faulthandler dumps 'Windows fatal exception: code 0xe06d7363'
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Thu Oct  5 06:00:29 2017
From: report at bugs.python.org (Fynn Be)
Date: Thu, 05 Oct 2017 10:00:29 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507197629.83.0.213398074469.issue31701@psf.upfronthosting.co.za>


Fynn Be <thefynnbe at gmail.com> added the comment:

Here is a git repository with a test module and a test script:
https://github.com/FynnBe/faulthandler-spam

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Thu Oct  5 06:08:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 10:08:57 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507198137.81.0.213398074469.issue31671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 3867 looks unpythonic to me. We usually don't check the type of arguments. This complicate and slow down a code.

Do you have a realistic example when the current behavior harms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 06:10:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 10:10:57 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507198257.52.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Hum, I ran again my microbenchmark on re.compile() cache:

haypo at selma$ ./python -m perf timeit -s 'import re; re_compile=re.compile' 're_compile("a", flags=2)' --duplicate=1024 -o ref.json  --inherit=PYTHONPATH -v

Sadly, the commit c1c47c166b1012d34f2c6e111ee9ccb5c4d12de7 made the cache slower:

Mean +- std dev: [ref] 364 ns +- 26 ns -> [patch] 545 ns +- 19 ns: 1.50x slower (+50%)

Just to check, I reverted the change on Scanner, the benchmark is still "560 ns +- 27 ns".


"if isinstance(flags, RegexFlag): flags = flags.value" added 181 nanoseconds? A quick "isinstance(flags, RegexFlag)" timeit microbenchmark says that this operation has a cost of 46.2 ns (+- 1.6 ns). Benchmarks are strange, as usual :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 06:15:27 2017
From: report at bugs.python.org (Fynn Be)
Date: Thu, 05 Oct 2017 10:15:27 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507198527.7.0.213398074469.issue31701@psf.upfronthosting.co.za>


Fynn Be <thefynnbe at gmail.com> added the comment:

In the github repository there is 'build.bat' that creates the mscv 14 solution, builds it and runs the 'test.py'.
Here is the output:
```
Windows fatal exception: code 0xe06d7363

Current thread 0x0000462c (most recent call first):
  File "test.py", line 5 in <module>
caught test error: c++ error message
```

The 'Windows fatal exception: code 0xe06d7363' is only caused by a c++ exception thrown (regardless if it is handled or not). More on the error code is here:
https://support.microsoft.com/de-de/help/185294/prb-exception-code-0xe06d7363-when-calling-win32-seh-apis

The last line 'caught test error: c++ error message' is generated within the test module, where the error is caught.

In larger projects these tracebacks spam the faulthandler's output, as this is valid code and occurs often (for example for an IndexError raised in a c++ extension to end a for loop).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Thu Oct  5 06:18:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 10:18:23 +0000
Subject: [issue31671] IntFlag makes re.compile slower
In-Reply-To: <1507028430.84.0.213398074469.issue31671@psf.upfronthosting.co.za>
Message-ID: <1507198703.9.0.213398074469.issue31671@psf.upfronthosting.co.za>


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

Serhiy: "PR 3867 looks unpythonic to me. We usually don't check the type of arguments. This complicate and slow down a code. Do you have a realistic example when the current behavior harms?"

No, I don't have any realistic example. I just noticed the bug and I was surprised. In practice, flags=2.0 instead of flags=2 is not totally wrong, it's okish to accept 2.0. Let's just forget this corner case. I abandon my change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31671>
_______________________________________

From report at bugs.python.org  Thu Oct  5 06:26:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 10:26:52 +0000
Subject: [issue30349] Preparation for advanced set syntax in regular
 expressions
In-Reply-To: <1494576853.44.0.660813121244.issue30349@psf.upfronthosting.co.za>
Message-ID: <1507199212.75.0.213398074469.issue30349@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Made a warning for '[' be emitted only at the start of a set. This significantly decrease the breakage of other code. I think we can get around without implicit union of nested sets, like in [_[0-9][:Latin:]]. This can be written as [_||[0-9]||[:Latin:]].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30349>
_______________________________________

From report at bugs.python.org  Thu Oct  5 07:48:20 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 11:48:20 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507204100.45.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

The code of the current faulthandler exception handler lives at:

https://github.com/python/cpython/blob/master/Modules/faulthandler.c#L364-L409

--

https://support.microsoft.com/de-de/help/185294/prb-exception-code-0xe06d7363-when-calling-win32-seh-apis

"""
Resolution

(...)
3. Within the Exceptions dialog box, select error 0xE06D7363.
4. Change the value of Action from Stop if not handled to Stop always.
"""

Are you asking to *ignore* all 0xE06D7363 exceptions?

I don't know well Windows exceptions. The latest change was bpo-30557, ignore non-fatal exceptions:

    /* bpo-30557: only log fatal exceptions */
    if (!(code & 0x80000000)) ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Thu Oct  5 08:16:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 12:16:42 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1507205802.68.0.213398074469.issue31690@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Added tests and the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Thu Oct  5 08:32:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 12:32:52 +0000
Subject: [issue31702] Allow to specify the number of rounds for SHA-* hashing
 in crypt
Message-ID: <1507206772.04.0.213398074469.issue31702@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Blowfish salt should contain the binary logarithm of the number of rounds (from 4 to 31) (see issue31664). SHA-* salt can contain an explicit number of rounds in the form '$rounds={value}$'. It is bound to the range from 1000 to 999999999, the default is 5000.

I propose to allow to specify the number of rounds in generated salt for SHA-* methods as well as for Blowfish. For unifying interface we can specify the number of rounds instead of its logarithm for Blowfish, and calculate the logarithm internally.

The question is what to do with the value that is not a power of two for Blowfish. Should we raise an error or silently replace it with the upper power of two?

----------
components: Library (Lib)
messages: 303760
nosy: christian.heimes, dstufft, gregory.p.smith, jafo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Allow to specify the number of rounds for SHA-* hashing in crypt
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31702>
_______________________________________

From report at bugs.python.org  Thu Oct  5 08:33:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 12:33:47 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1507206827.9.0.213398074469.issue31664@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In issue31702 I propose related improvement for the SHA-* methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:08:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:08:52 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507208932.74.0.213398074469.issue31178@psf.upfronthosting.co.za>


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


----------
pull_requests: +3867

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:12:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:12:25 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507209145.37.0.213398074469.issue31178@psf.upfronthosting.co.za>


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

A colleague packaging Python for Red Hat Entreprise Linux reported me that tests hang randomly on test_exception_errpipe_bad_data() of test_subprocess. I don't know why exactly, but using strace, I noticed that the "unit test" calls os.waitpid() with the pid returned by the mocked fork_exec(): pid 0. So the test calls os.waitpid(0, 0).

In a REPL on my Fedora 26, os.waitpid(0, 0) raises "ChildProcessError: [Errno 10] No child processes". I'm not sure that waitpid() is the cause of the hang, but it doesn't seem correct to me to call waitpid() with the result of a mock function, since the mock doesn't create a real child process.

Attached PR 3896 mocks also os.waitpid() to fix this bug. I reopen the issue to discuss this bug in the new test added in this issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:31:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:31:34 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507210294.25.0.213398074469.issue31178@psf.upfronthosting.co.za>


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

> In a REPL on my Fedora 26, os.waitpid(0, 0) raises "ChildProcessError: [Errno 10] No child processes". I'm not sure that waitpid() is the cause of the hang, (...)

Oh wait, now I understood the full picture.

Summary:

* 2 new tests were added to test_subprocess and these tests call waitpid(0, 0) by mistake
* In general, waitpid(0, 0) returns immediately and the code handles it properly
* Sometimes, a previous test leaks a child process and so waitpid(0, 0) takes a few seconds or can even block

--

Running tests leak randomly child processes. See for example my recent test_socketserver fix in Python 3.6: commit fdcf3e9629201ef725af629d99e02215a2d657c8. This commit is *not* part of the recent Python 3.6.3 release, tested by my colleague.

This fix is for the bug bpo-31593: test_socketserver leaked *randomly* child processes. Depending on the system load, waitpid() was called or not called to read the child process exit status.

If you run "./python -m test test_socketserver test_subprocess" and test_socketserver() doesn't call waitpid() on a single process, it's possible that test_subprocess hangs on waitpid(0, 0): waiting on the process spawned by test_socketserver.

test_socketserver is just one example, I fixed many other bugs in the Python test suite. Running Python tests in subprocesses using "./python -m test -jN ...", at least -j1, reduces the effect of the bug.

Short script to explain the bug:
---
import subprocess, sys, os, time

args = [sys.executable, '-c', 'import time; time.sleep(2)']
proc = subprocess.Popen(args)
t0 = time.monotonic()
print("waitpid(0, 0)...")
pid, status = os.waitpid(0, 0)
dt = time.monotonic() - t0
print("%.1f sec later: waitpid(0, 0) -> %s" % (dt, (pid, status)))
proc.wait()
---

This script takes 3 seconds, since a test leaked a child process which takes time to complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:32:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:32:55 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507210375.41.0.213398074469.issue31178@psf.upfronthosting.co.za>


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


New changeset 11045c9d8a21dd9bd182a3939189db02815f9783 by Victor Stinner in branch 'master':
bpo-31178: Mock os.waitpid() in test_subprocess (#3896)
https://github.com/python/cpython/commit/11045c9d8a21dd9bd182a3939189db02815f9783


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:34:39 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Oct 2017 13:34:39 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507210479.21.0.213398074469.issue31178@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3868
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:41:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:41:53 +0000
Subject: [issue31703] [EASY] Running test_builtin twice fails on input tty
 tests
Message-ID: <1507210913.82.0.213398074469.issue31703@psf.upfronthosting.co.za>


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

haypo at selma$ ./python -m test test_builtin test_builtin -v

======================================================================
FAIL: test_input_tty_non_ascii (test.test_builtin.PtyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/master/Lib/test/test_builtin.py", line 1717, in test_input_tty_non_ascii
    self.check_input_tty("prompt?", b"quux\xe9", "utf-8")
  File "/home/haypo/prog/python/master/Lib/test/test_builtin.py", line 1708, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +


======================================================================
FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.PtyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/master/Lib/test/test_builtin.py", line 1721, in test_input_tty_non_ascii_unicode_errors
    self.check_input_tty("prompt?", b"quux\xe9", "ascii")
  File "/home/haypo/prog/python/master/Lib/test/test_builtin.py", line 1708, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +

----------
components: Tests
keywords: easy
messages: 303765
nosy: haypo
priority: normal
severity: normal
status: open
title: [EASY] Running test_builtin twice fails on input tty tests
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31703>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:50:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 13:50:59 +0000
Subject: [issue31703] [EASY] Running test_builtin twice fails on input tty
 tests
In-Reply-To: <1507210913.82.0.213398074469.issue31703@psf.upfronthosting.co.za>
Message-ID: <1507211459.58.0.213398074469.issue31703@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue13886 (and several other issues).

Why do you think that this issue is easy?

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> readline-related test_builtin failure

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31703>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:51:22 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:51:22 +0000
Subject: [issue31703] [EASY] Running test_builtin twice fails on input tty
 tests
In-Reply-To: <1507210913.82.0.213398074469.issue31703@psf.upfronthosting.co.za>
Message-ID: <1507211482.26.0.213398074469.issue31703@psf.upfronthosting.co.za>


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

> Why do you think that this issue is easy?

I'm not sure that it's easy :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31703>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:52:00 2017
From: report at bugs.python.org (=?utf-8?b?w4FsdmFybyBNdcOxb3o=?=)
Date: Thu, 05 Oct 2017 13:52:00 +0000
Subject: [issue31704] HTTP check lowercase response from proxy
Message-ID: <1507211520.07.0.213398074469.issue31704@psf.upfronthosting.co.za>


New submission from ?lvaro Mu?oz <alvaro.munoz at gmail.com>:

Recently faced an issue with a proxy responding in lowercase http, which caused this:

ProtocolError('Connection aborted.', BadStatusLine('http/1.1 200 connection established\r\n',))

Changing the string to uppercase before checking if it starts with HTTP fixes this issue and allows to use this proxy.

I know that the proxy is at fault here, but seeing as other applications (web browsers, office suite, text editors, etc.) still work behind this proxy, I think it might be a reasonable fix to have...

----------
components: Library (Lib)
messages: 303768
nosy: alvaromunoz
priority: normal
pull_requests: 3869
severity: normal
status: open
title: HTTP check lowercase response from proxy
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31704>
_______________________________________

From report at bugs.python.org  Thu Oct  5 09:57:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 13:57:02 +0000
Subject: [issue31596] expose pthread_getcpuclockid in time module
In-Reply-To: <1506450794.16.0.162056328414.issue31596@psf.upfronthosting.co.za>
Message-ID: <1507211822.23.0.213398074469.issue31596@psf.upfronthosting.co.za>


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

The test is too strict, it fails on many buildbots.

Four examples:

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

======================================================================
FAIL: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_time.py", line 100, in test_pthread_getcpuclockid
    self.assertLessEqual(t2, t3)
AssertionError: 16.309616 not less than or equal to 16.309358

http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/1466/steps/test/logs/stdio

======================================================================
FAIL: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_time.py", line 99, in test_pthread_getcpuclockid
    self.assertLessEqual(t1, t2)
AssertionError: 0.938456056 not less than or equal to 0.8324859600000001

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%20Non-Debug%203.x/builds/999/steps/test/logs/stdio

======================================================================
FAIL: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current.nondebug/build/Lib/test/test_time.py", line 100, in test_pthread_getcpuclockid
    self.assertLessEqual(t2, t3)
AssertionError: 0.813547 not less than or equal to 0.81335

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

======================================================================
FAIL: test_pthread_getcpuclockid (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_time.py", line 100, in test_pthread_getcpuclockid
    self.assertLessEqual(t2, t3)
AssertionError: 1.121773 not less than or equal to 1.121547

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31596>
_______________________________________

From report at bugs.python.org  Thu Oct  5 10:10:39 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 14:10:39 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1507212639.42.0.213398074469.issue13886@psf.upfronthosting.co.za>


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

bpo-31703 has been marked as a duplicate of this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Thu Oct  5 10:25:07 2017
From: report at bugs.python.org (Fynn Be)
Date: Thu, 05 Oct 2017 14:25:07 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507213507.33.0.213398074469.issue31701@psf.upfronthosting.co.za>


Fynn Be <thefynnbe at gmail.com> added the comment:

> Are you asking to *ignore* all 0xE06D7363 exceptions?
Yes. This error is only indicating that an error was thrown, regardless if it was handled or not. Therefore it should not be treated as fatal, but it is by faulthandler: 'bool(0xE06D7363 & 0x80000000) == True'

>  with the initial "E" standing for "exception" and the final 3 bytes (0x6D7363) representing the ASCII values of "msc"
https://support.microsoft.com/de-de/help/185294/prb-exception-code-0xe06d7363-when-calling-win32-seh-apis
In this context it seems like a coincidence to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Thu Oct  5 10:35:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Oct 2017 14:35:14 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1507214114.67.0.213398074469.issue13886@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

As well as other 5 bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Thu Oct  5 11:05:16 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Oct 2017 15:05:16 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507215916.97.0.213398074469.issue31701@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

We may just need to special case some well known exception codes for MSVC and the CLR, though if they're handled we may be dumping on the first chance and not the second chance handling.

If I get a chance to dig into the docs and code I'll take a look, but it's been years since I really did anything with SEH (apart from the recent filtering change, which was pretty trivial).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Thu Oct  5 11:07:43 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Oct 2017 15:07:43 +0000
Subject: [issue31694] Running Windows installer with LauncherOnly=1 should not
 register the version as installed
In-Reply-To: <1507143159.66.0.213398074469.issue31694@psf.upfronthosting.co.za>
Message-ID: <1507216063.28.0.213398074469.issue31694@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Agreed, and the underlying cause is also linked to the registration being wrong in some other ways.

The fix requires rearchitecting the installer again, though less dramatically than last time. Won't happen for3.6.4, but we might get 3.7.

----------
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31694>
_______________________________________

From report at bugs.python.org  Thu Oct  5 11:43:34 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 05 Oct 2017 15:43:34 +0000
Subject: [issue31692] Test `test_huntrleaks` fails in debug build with
 COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507218214.43.0.213398074469.issue31692@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Thu Oct  5 11:46:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 15:46:08 +0000
Subject: [issue31180] test_multiprocessing_spawn hangs randomly
In-Reply-To: <1502400975.07.0.689018470672.issue31180@psf.upfronthosting.co.za>
Message-ID: <1507218368.52.0.213398074469.issue31180@psf.upfronthosting.co.za>


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

New failure: AMD64 FreeBSD 10.x Shared 3.6

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.x%20Shared%203.6/builds/550/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31180>
_______________________________________

From report at bugs.python.org  Thu Oct  5 12:05:32 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 05 Oct 2017 16:05:32 +0000
Subject: [issue31556] asyncio.wait_for can cancel futures faster with
 timeout==0
In-Reply-To: <1506113277.58.0.317559444537.issue31556@psf.upfronthosting.co.za>
Message-ID: <1507219532.06.0.213398074469.issue31556@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31556>
_______________________________________

From report at bugs.python.org  Thu Oct  5 12:11:54 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 05 Oct 2017 16:11:54 +0000
Subject: [issue31353] Implement PEP 553 - built-in breakpoint()
In-Reply-To: <1504644260.05.0.176716626813.issue31353@psf.upfronthosting.co.za>
Message-ID: <1507219914.42.0.213398074469.issue31353@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31353>
_______________________________________

From report at bugs.python.org  Thu Oct  5 12:46:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Oct 2017 16:46:52 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1507222012.23.0.213398074469.issue31626@psf.upfronthosting.co.za>


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


----------
pull_requests: +3870

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Thu Oct  5 12:59:36 2017
From: report at bugs.python.org (Oren Milman)
Date: Thu, 05 Oct 2017 16:59:36 +0000
Subject: [issue31092] multiprocessing.Manager() race condition
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507222776.14.0.213398074469.issue31092@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

IIUC:
In Lang's example, doing `queue = None` caused the destruction of the shared
queue, which caused a call to BaseProxy._decref() (in multiprocessing/managers.py),
which dispatched a decref request to the manager's server process.

Meanwhile, the pool's worker process (in function worker() in multiprocessing/pool.py)
tries to retrieve a task from its task queue, by calling inqueue.get().
The get() method unpickles the first pickled task in the queue, which is the
function and arguments that we passed to apply_async().
The unpickling of the shared queue causes creating a proxy object for the
shared queue, in which BaseProxy.__init__() is called, which calls
BaseProxy._incref(), which dispatches an incref request to the manager's server
process.

Unfortunately, the decref request gets to the server before the incref request.
So when the server receives the decref request (in Server.handle_request()),
and accordingly calls Server.decref(), the refcount of the shared queue in the
server is 1, so the refcount is decremented to 0, and the shared queue is
disposed.
Then, when the server receives the incref request, it tries to increment the
refcount of the shared queue (in Server.incref()), but can't find it in its
refcount dict, so it raises the KeyError.
(If, for example, you added a 'sleep(0.5)' before the call to dispatch() in
BaseProxy._decref(), the incref request would win the race, and the KeyError
wouldn't be raised.)


Should we fix this?
Or is it the responsibility of the user to not destroy shared objects too soon?
(In that case, maybe we should mention it in the docs?)


The situation in the example of Prof Plum is similar.
Also, note that this issue is not specific to using pool workers or to
Manager.Queue. For example, we get a similar error (for similar reasons) in
this code:

from multiprocessing import Process, Manager
from time import sleep
if __name__ == '__main__':
    with Manager() as manager:
        shared_list = manager.list()
        p = Process(target=sorted, args=(shared_list,))
        p.start()
        # sleep(0.5)
        shared_list = None
        p.join()

----------
components: +Library (Lib)
nosy: +Oren Milman
type: crash -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Thu Oct  5 12:59:54 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 05 Oct 2017 16:59:54 +0000
Subject: [issue31556] asyncio.wait_for can cancel futures faster with
 timeout==0
In-Reply-To: <1506113277.58.0.317559444537.issue31556@psf.upfronthosting.co.za>
Message-ID: <1507222794.14.0.213398074469.issue31556@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Note, that this will not be backported to 3.6, as it behaves in a slightly incompatible way.  I consider this patch as an enhancement that makes 'asyncio.wait_for' semantics easier to reason about and more practical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31556>
_______________________________________

From report at bugs.python.org  Thu Oct  5 13:09:39 2017
From: report at bugs.python.org (Oren Milman)
Date: Thu, 05 Oct 2017 17:09:39 +0000
Subject: [issue31092] multiprocessing.Manager() race condition
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507223379.66.0.213398074469.issue31092@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Prof Plum, i changed the type of the issue to 'behavior', because Lang and me
both got a KeyError. if your interpreter actually crashed, please change it
back to 'crash'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Thu Oct  5 13:58:38 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Oct 2017 17:58:38 +0000
Subject: [issue31523] Windows build file fixes
In-Reply-To: <1505862497.47.0.608465001142.issue31523@psf.upfronthosting.co.za>
Message-ID: <1507226318.29.0.213398074469.issue31523@psf.upfronthosting.co.za>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +3871
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31523>
_______________________________________

From report at bugs.python.org  Thu Oct  5 14:05:13 2017
From: report at bugs.python.org (Coady)
Date: Thu, 05 Oct 2017 18:05:13 +0000
Subject: [issue31697] Regression in futures.as_completed with
 ProcessPoolExecutor.
In-Reply-To: <1507160850.08.0.213398074469.issue31697@psf.upfronthosting.co.za>
Message-ID: <1507226713.64.0.213398074469.issue31697@psf.upfronthosting.co.za>


Coady <aric.coady at gmail.com> added the comment:

Reproduced on the python docker image because the cpu count is so low.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31697>
_______________________________________

From report at bugs.python.org  Thu Oct  5 14:54:36 2017
From: report at bugs.python.org (Prof Plum)
Date: Thu, 05 Oct 2017 18:54:36 +0000
Subject: [issue31092] multiprocessing.Manager() race condition
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507229676.75.0.213398074469.issue31092@psf.upfronthosting.co.za>


Prof Plum <dwyerfire at gmail.com> added the comment:

Oh I see, I thought getting an error that caused the python code execution to terminate was considered a "crash".

On the note of whether you should fix this I think the answer is yes. When I call pool.apply_async() I expect it only to return when the worker process has been started and finished it's initialization process (i.e. sending the incr-ref request). That being said I could see people wanting to utilize the minor performance gain of having the worker start AND run asynchronously so I think this option should be available via a boolean arg to apply_async() but it should be off by default because that is the safer and intuitive behavior of apply_async().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Thu Oct  5 15:01:44 2017
From: report at bugs.python.org (pdox)
Date: Thu, 05 Oct 2017 19:01:44 +0000
Subject: [issue31596] expose pthread_getcpuclockid in time module
In-Reply-To: <1506450794.16.0.162056328414.issue31596@psf.upfronthosting.co.za>
Message-ID: <1507230104.74.0.213398074469.issue31596@psf.upfronthosting.co.za>


pdox <pdox at alum.mit.edu> added the comment:

This looks specific to FreeBSD and s390x. Those platforms might not provide the same cpu-time clock consistency guarantees as Linux+glibc+x86. Would it be ok to just disable the ordering check for those systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31596>
_______________________________________

From report at bugs.python.org  Thu Oct  5 15:52:02 2017
From: report at bugs.python.org (Lele Gaifax)
Date: Thu, 05 Oct 2017 19:52:02 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1507233122.29.0.213398074469.issue27645@psf.upfronthosting.co.za>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

I rebased my v2 set of changesets into a new branch: https://github.com/lelit/cpython/tree/sqlite-backup-api-v3

I really don't know if anybody is interested beyond me, I did everything has been suggested/requested, and honestly I feel a bit discouraged: in the good'n'old days even potentially disrupting and invasive patches of mine have been accepted by the one&only core developer, now for an harmless, tested and documented single new feature an year and half has passed with almost no progress....

Anyway, I guess that this is my last attempt, let's hope... Let me know if I should close the PR#377 and reopen a new one, or whatever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Thu Oct  5 15:58:24 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 05 Oct 2017 19:58:24 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
Message-ID: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

The issue is reproducible on a CentOS 7.4 on ppc64le architecture. It passes successfully on other arch's (however the other power pc arch's might also be affected).

How to reproduce:

Compile python 3.6 from source.

Run ./python3 -m test --verbose test_socket

And it fails with:

ERROR: test_sha256 (test.test_socket.LinuxKernelCryptoAPI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/test/cpython/Lib/test/test_socket.py", line 5424, in test_sha256
    op.sendall(b"abc")
OSError: [Errno 126] Required key not available

----------
components: Tests
messages: 303783
nosy: cstratak
priority: normal
severity: normal
status: open
title: test_sha256 from test_socket fails on ppc64le arch
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Thu Oct  5 15:58:44 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 05 Oct 2017 19:58:44 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507233524.62.0.213398074469.issue31705@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Thu Oct  5 16:12:52 2017
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Freitag?=)
Date: Thu, 05 Oct 2017 20:12:52 +0000
Subject: [issue31706] urlencode should accept generator as values for mappings
 when doseq=True
Message-ID: <1507234372.12.0.213398074469.issue31706@psf.upfronthosting.co.za>


New submission from Fran?ois Freitag <mail+python at franek.fr>:

The urlencode documentation states that:
The value element in itself can be a sequence and in that case, if the optional parameter doseq is evaluates to True, individual key=value pairs separated by '&' are generated for each element of the value sequence for the key.

Passing a generator as the value gives unexpected results:
>>> from urllib.parse import urlencode
>>> def gen():
...     yield from range(2)
>>> urlencode({'a': gen()}, doseq=True)
'a=%3Cgenerator+object+gen+at+0x7f35ff78db48%3E'

A list gives:
>>> urlencode({'a': [0, 1]}, doseq=True)
'a=0&a=1'

----------
components: Library (Lib)
messages: 303784
nosy: freitafr
priority: normal
severity: normal
status: open
title: urlencode should accept generator as values for mappings when doseq=True
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31706>
_______________________________________

From report at bugs.python.org  Thu Oct  5 16:35:40 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Oct 2017 20:35:40 +0000
Subject: [issue31523] Windows build file fixes
In-Reply-To: <1505862497.47.0.608465001142.issue31523@psf.upfronthosting.co.za>
Message-ID: <1507235740.55.0.213398074469.issue31523@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 2084b30e540d88b9fc752c5bdcc2f24334af4f2b by Steve Dower in branch 'master':
bpo-31523: Reliability improvements to the Windows build files (#3900)
https://github.com/python/cpython/commit/2084b30e540d88b9fc752c5bdcc2f24334af4f2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31523>
_______________________________________

From report at bugs.python.org  Thu Oct  5 16:39:00 2017
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Freitag?=)
Date: Thu, 05 Oct 2017 20:39:00 +0000
Subject: [issue31706] urlencode should accept generator as values for mappings
 when doseq=True
In-Reply-To: <1507234372.12.0.213398074469.issue31706@psf.upfronthosting.co.za>
Message-ID: <1507235940.28.0.213398074469.issue31706@psf.upfronthosting.co.za>


Change by Fran?ois Freitag <mail+python at franek.fr>:


----------
keywords: +patch
pull_requests: +3872
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31706>
_______________________________________

From report at bugs.python.org  Thu Oct  5 16:44:23 2017
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Freitag?=)
Date: Thu, 05 Oct 2017 20:44:23 +0000
Subject: [issue31706] urlencode should accept generator as values for mappings
 when doseq=True
In-Reply-To: <1507234372.12.0.213398074469.issue31706@psf.upfronthosting.co.za>
Message-ID: <1507236263.93.0.213398074469.issue31706@psf.upfronthosting.co.za>


Change by Fran?ois Freitag <mail+python at franek.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31706>
_______________________________________

From report at bugs.python.org  Thu Oct  5 17:05:59 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Oct 2017 21:05:59 +0000
Subject: [issue31523] Windows build file fixes
In-Reply-To: <1505862497.47.0.608465001142.issue31523@psf.upfronthosting.co.za>
Message-ID: <1507237559.55.0.213398074469.issue31523@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3873

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31523>
_______________________________________

From report at bugs.python.org  Thu Oct  5 17:09:32 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Oct 2017 21:09:32 +0000
Subject: [issue31523] Windows build file fixes
In-Reply-To: <1505862497.47.0.608465001142.issue31523@psf.upfronthosting.co.za>
Message-ID: <1507237772.15.0.213398074469.issue31523@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 051295a8c57cc649fa5eaa43526143984a147411 by Steve Dower (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31523: Reliability improvements to the Windows build files (GH-3900) (#3902)
https://github.com/python/cpython/commit/051295a8c57cc649fa5eaa43526143984a147411


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31523>
_______________________________________

From report at bugs.python.org  Thu Oct  5 17:11:32 2017
From: report at bugs.python.org (Greg Couch)
Date: Thu, 05 Oct 2017 21:11:32 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1507237892.15.0.213398074469.issue29095@psf.upfronthosting.co.za>


Greg Couch <gregc at cgl.ucsf.edu> added the comment:

The problem with compiling OpenSSL from source is that it doesn't know how to access the root certificates needed for verification on Mac OS X.  See issue17128 for more details.

----------
nosy: +gregcouch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Oct  5 19:08:26 2017
From: report at bugs.python.org (Ben Burrill)
Date: Thu, 05 Oct 2017 23:08:26 +0000
Subject: [issue31707] Irrational fractions
Message-ID: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>


New submission from Ben Burrill <bburrill98 at gmail.com>:

fractions.Fraction enforces its numerator and denominator to be rational.  This is a good idea for purely numeric fractions, but the abstractions that fractions.Fraction offers would also be useful for more abstract fractions.

Some places where this might be useful would be fractions of polynomial types or fractions with abstract irrational numeric types, like F(SquareRoot(3), 2).

This could be accomplished by having a more general Fraction superclass or by removing the requirement of rationality from fractions.Fraction.  It is not trivial to create a subclass of Fraction that does this because the operators are hardcoded to use Fraction and initiation is done in __new__.

----------
components: Library (Lib)
messages: 303788
nosy: Ben Burrill
priority: normal
severity: normal
status: open
title: Irrational fractions
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Thu Oct  5 19:28:27 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Oct 2017 23:28:27 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1507246107.39.0.213398074469.issue27645@psf.upfronthosting.co.za>


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

If you are talking about Gerhard, if he was still around you'd probably get a similar response, but he hasn't been around much.  So this is somewhat of an orphaned module currently and it takes longer for an issue to get traction.  One of the drawbacks of the open-source-volunteer model :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Thu Oct  5 19:49:43 2017
From: report at bugs.python.org (Ben Burrill)
Date: Thu, 05 Oct 2017 23:49:43 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507247383.2.0.213398074469.issue31707@psf.upfronthosting.co.za>


Change by Ben Burrill <bburrill98 at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Thu Oct  5 20:58:12 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 Oct 2017 00:58:12 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507251492.02.0.213398074469.issue31707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The fractions module isn't easily extended to support this proposal.  It was designed around a gcd() step and assumes integer numerators and denominators throughout.  Also, the Fraction class is registered with numbers.Rational() which implies some specific behaviors including inoperability with various other classes.

In additionl, the standard library also doesn't yet support unevaluated rationals like SquareRoot(3).  I suggest looking at the sympy module which may already have everything you need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Thu Oct  5 22:29:41 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Oct 2017 02:29:41 +0000
Subject: [issue11205] Evaluation order of dictionary display is different from
 reference manual.
In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za>
Message-ID: <1507256981.34.0.213398074469.issue11205@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm unlikely to ever get to this (especially as 3.5 is now in security-fix only mode), so closing it again.

----------
nosy: +freakboy, freakboy3742
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11205>
_______________________________________

From report at bugs.python.org  Thu Oct  5 22:46:49 2017
From: report at bugs.python.org (Ben Burrill)
Date: Fri, 06 Oct 2017 02:46:49 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507258009.66.0.213398074469.issue31707@psf.upfronthosting.co.za>


Ben Burrill <bburrill98 at gmail.com> added the comment:

The core operators, like multiplication and division, should work for any type that defines the right operators.  Hashing is tricky, and reducing the fraction is pretty much off the table.  This is why I suggested a superclass.  I'll try making a patch sometime soon.

I am aware of sympy and am not proposing that the standard library stray too far into symbolic mathematics.  Sympy's re-invention of the fraction makes sense given sympy's scope, but simpler libraries that offer other abstract math features (like one that just implemented a simple Polynomial type) would benefit from using fractions.Fraction.

This change would probably make it so that sympy symbols worked with fractions.Fraction, which although unnecessary, might be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Thu Oct  5 23:24:51 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 03:24:51 +0000
Subject: [issue30406] async and await should be keywords in 3.7
In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za>
Message-ID: <1507260291.05.0.213398074469.issue30406@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ac317700ce7439e38a8b420218d9a5035bba92ed by Yury Selivanov (Jelle Zijlstra) in branch 'master':
bpo-30406: Make async and await proper keywords (#1669)
https://github.com/python/cpython/commit/ac317700ce7439e38a8b420218d9a5035bba92ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30406>
_______________________________________

From report at bugs.python.org  Thu Oct  5 23:28:00 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 03:28:00 +0000
Subject: [issue30406] async and await should be keywords in 3.7
In-Reply-To: <1495229262.01.0.300246152317.issue30406@psf.upfronthosting.co.za>
Message-ID: <1507260480.53.0.213398074469.issue30406@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks a lot, Jelle!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30406>
_______________________________________

From report at bugs.python.org  Fri Oct  6 00:15:16 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Oct 2017 04:15:16 +0000
Subject: [issue31696] don't mention GCC in sys.version when built with Clang
In-Reply-To: <1507150585.16.0.213398074469.issue31696@psf.upfronthosting.co.za>
Message-ID: <1507263316.92.0.213398074469.issue31696@psf.upfronthosting.co.za>


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


New changeset 7faf7e50757dde2cb8583ee08ef31f4b8312e44f by Benjamin Peterson in branch 'master':
closes bpo-31696: don't mention GCC in sys.version when building with clang (#3891)
https://github.com/python/cpython/commit/7faf7e50757dde2cb8583ee08ef31f4b8312e44f


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31696>
_______________________________________

From report at bugs.python.org  Fri Oct  6 00:23:32 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 04:23:32 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
Message-ID: <1507263812.11.0.213398074469.issue31708@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
assignee: yselivanov
components: Interpreter Core
nosy: yselivanov
priority: normal
severity: normal
status: open
title: Allow use of asynchronous generator expressions in synchronous functions
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 00:23:47 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 04:23:47 +0000
Subject: [issue31709] Drop support for asynchronous __aiter__
Message-ID: <1507263827.12.0.213398074469.issue31709@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

As discussed in issue 27243, we want to drop support of asynchronous __aiter__ in Python 3.7.

Together with issue 30406, this will enable us to add support for using asynchronous generator expressions in synchronous functions (issue 31708)

----------
assignee: yselivanov
components: Interpreter Core
messages: 303796
nosy: ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: Drop support for asynchronous __aiter__
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31709>
_______________________________________

From report at bugs.python.org  Fri Oct  6 00:25:37 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 04:25:37 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
Message-ID: <1507263937.93.0.213398074469.issue31708@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Prior to Python 3.7 we couldn't enable use of asynchronous generator expressions in synchronous functions:

    async arange(n):
        for i in range(n):
            yield i

    def make_arange(n):
        return (i async for i in arange(n))

----------
dependencies: +Drop support for asynchronous __aiter__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 00:28:24 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 04:28:24 +0000
Subject: [issue31709] Drop support for asynchronous __aiter__
In-Reply-To: <1507263827.12.0.213398074469.issue31709@psf.upfronthosting.co.za>
Message-ID: <1507264104.95.0.213398074469.issue31709@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +3874
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31709>
_______________________________________

From report at bugs.python.org  Fri Oct  6 00:34:43 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 Oct 2017 04:34:43 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507264483.59.0.213398074469.issue31707@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Put me down for -1.  This doesn't seem like standard library material. It doesn't seem to address a common need and it would add complexity to an already complicated module (nor does it seem to have a good fit with the numeric tower).  The proposal seems like something that should exist outside the standard library (especially since we don't already provide interoperable types like SquareRoot(3)).

----------
priority: normal -> low
type: behavior -> enhancement
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Fri Oct  6 01:09:37 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Oct 2017 05:09:37 +0000
Subject: [issue31596] expose pthread_getcpuclockid in time module
In-Reply-To: <1506450794.16.0.162056328414.issue31596@psf.upfronthosting.co.za>
Message-ID: <1507266577.61.0.213398074469.issue31596@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +3875

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31596>
_______________________________________

From report at bugs.python.org  Fri Oct  6 01:14:44 2017
From: report at bugs.python.org (pmpp)
Date: Fri, 06 Oct 2017 05:14:44 +0000
Subject: [issue31710] setup.py: _ctypes won't getbuilt when system ffi is only
 in $PREFIX
Message-ID: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>


New submission from pmpp <pmpp.pub at gmail.com>:

--with-system-ffi is mandatory for linux build but no way is provided ( eg --with-ffi-includes= --with-ffi-libs= ) so setup.py can detect libffi already built in $PREFIX and $EPREFIX/lib.

even if cflags/ldflags are ok , _ctypes build will be skipped with reason:
INFO: Could not locate ffi libs and/or headers

test condition: crystax-ndk toward android-19 on ubuntu xenial 32 bits

----------
components: Cross-Build
messages: 303799
nosy: Alex.Willmer, pmpp
priority: normal
severity: normal
status: open
title: setup.py: _ctypes won't getbuilt when system ffi is only in $PREFIX
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Fri Oct  6 01:37:21 2017
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 06 Oct 2017 05:37:21 +0000
Subject: [issue31710] setup.py: _ctypes won't getbuilt when system ffi is only
 in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1507268241.3.0.213398074469.issue31710@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +Chi Hsuan Yen, doko, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Fri Oct  6 01:50:44 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 06 Oct 2017 05:50:44 +0000
Subject: [issue31596] expose pthread_getcpuclockid in time module
In-Reply-To: <1506450794.16.0.162056328414.issue31596@psf.upfronthosting.co.za>
Message-ID: <1507269044.64.0.213398074469.issue31596@psf.upfronthosting.co.za>


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


New changeset 86566702f311f8e90600e85350f6b6769a384ea5 by Benjamin Peterson in branch 'master':
weaken pthread_getcpuclockid test (more bpo-31596) (#3904)
https://github.com/python/cpython/commit/86566702f311f8e90600e85350f6b6769a384ea5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31596>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:04:49 2017
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 06 Oct 2017 06:04:49 +0000
Subject: [issue31710] setup.py: _ctypes won't getbuilt when system ffi is only
 in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1507269889.58.0.213398074469.issue31710@psf.upfronthosting.co.za>


Chi Hsuan Yen <yan12125 at gmail.com> added the comment:

> even if cflags/ldflags are ok 

Might be this. setup.py doesn't use -I flags in $CFLAGS. It looks into $CPPFLAGS only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:08:59 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:08:59 +0000
Subject: [issue31709] Drop support for asynchronous __aiter__
In-Reply-To: <1507263827.12.0.213398074469.issue31709@psf.upfronthosting.co.za>
Message-ID: <1507270139.92.0.213398074469.issue31709@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset faa135acbfcd55f79fb97f7525c8aa6f5a5b6a22 by Yury Selivanov in branch 'master':
bpo-31709: Drop support for asynchronous __aiter__. (#3903)
https://github.com/python/cpython/commit/faa135acbfcd55f79fb97f7525c8aa6f5a5b6a22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31709>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:09:14 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:09:14 +0000
Subject: [issue31709] Drop support for asynchronous __aiter__
In-Reply-To: <1507263827.12.0.213398074469.issue31709@psf.upfronthosting.co.za>
Message-ID: <1507270154.2.0.213398074469.issue31709@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31709>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:14:22 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:14:22 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
In-Reply-To: <1507263937.93.0.213398074469.issue31708@psf.upfronthosting.co.za>
Message-ID: <1507270462.82.0.213398074469.issue31708@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
keywords: +patch
pull_requests: +3876
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:22:59 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:22:59 +0000
Subject: [issue31709] Drop support for asynchronous __aiter__
In-Reply-To: <1507263827.12.0.213398074469.issue31709@psf.upfronthosting.co.za>
Message-ID: <1507270979.02.0.213398074469.issue31709@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +3877

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31709>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:26:15 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:26:15 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
In-Reply-To: <1507263937.93.0.213398074469.issue31708@psf.upfronthosting.co.za>
Message-ID: <1507271175.29.0.213398074469.issue31708@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

(this is per PEP 530: https://www.python.org/dev/peps/pep-0530/#asynchronous-comprehensions)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:27:23 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:27:23 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
In-Reply-To: <1507263937.93.0.213398074469.issue31708@psf.upfronthosting.co.za>
Message-ID: <1507271243.18.0.213398074469.issue31708@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:31:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 06:31:14 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507271474.52.0.213398074469.issue31707@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Concur with Raymond.

Even multiplication doesn't work for irrational numerator and denominator, since gcd() is not applicable to them.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:58:30 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:58:30 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
In-Reply-To: <1507263937.93.0.213398074469.issue31708@psf.upfronthosting.co.za>
Message-ID: <1507273110.12.0.213398074469.issue31708@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b8ab9d3fc816f85f4d6dbef12b7414e6dc10e4dd by Yury Selivanov in branch 'master':
bpo-31708: Allow async generator expressions in synchronous functions (#3905)
https://github.com/python/cpython/commit/b8ab9d3fc816f85f4d6dbef12b7414e6dc10e4dd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 02:58:58 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 Oct 2017 06:58:58 +0000
Subject: [issue31708] Allow use of asynchronous generator expressions in
 synchronous functions
In-Reply-To: <1507263937.93.0.213398074469.issue31708@psf.upfronthosting.co.za>
Message-ID: <1507273138.11.0.213398074469.issue31708@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31708>
_______________________________________

From report at bugs.python.org  Fri Oct  6 03:06:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 07:06:27 +0000
Subject: [issue31706] urlencode should accept generator as values for mappings
 when doseq=True
In-Reply-To: <1507234372.12.0.213398074469.issue31706@psf.upfronthosting.co.za>
Message-ID: <1507273587.33.0.213398074469.issue31706@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Extending urlencode() to accept iterables instead of just sequences of values makes sense to me. There is no principal reason of requiring sequences. But you need to update the documentation, docstrings and comments.

While we are here, we can generalize urlencode() in other aspect. Currently it accepts either mapping or a sequence of 2-tuples. It could be accept an iterable of 2-tuples (or even an iterable of 2-element sequences or 2-element iterables).

----------
nosy: +serhiy.storchaka
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31706>
_______________________________________

From report at bugs.python.org  Fri Oct  6 04:47:48 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Fri, 06 Oct 2017 08:47:48 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507279668.88.0.213398074469.issue31707@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

I would like to provide some colour to this discussion. In a former life I have coded these during my studies. Ben is talking about implementing the Field of Fractions of an Integral Domain. See https://en.wikipedia.org/wiki/Field_of_fractions

The way Fraction is implemented it has a unique representation for each fraction in Q and uses GCD. This requires us to strengthen the condition of Integral Domain to a Euclidean Domain where the Euclidean Function fulfills the role of %. I.e. Serhiy: it would only support exactly those rings that support gcd! See https://en.wikipedia.org/wiki/Euclidean_domain

One could implement a base class called (Euclidean)FractionField that generalizes to Euclidean domains. For future reference, there are a few practical niggles I want to record:
- how to deal with basic numeric types?
- Euclidean Domain needs to implement __abs__ to get a canonical denominator, unless gcd works out magically like it does in Z?

The added advantage beside being able to use the FractionField class as Ben suggests is that it splits up the mechanics of parsing/creating/casting to/from various basic numeric types from the mathematical operations in a fraction field making the code clearer.

I am happy to assist Ben with the patch if he wants any help.

----------
nosy: +Henk-Jaap Wagenaar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Fri Oct  6 05:03:08 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Oct 2017 09:03:08 +0000
Subject: [issue31707] Irrational fractions
In-Reply-To: <1507244906.43.0.213398074469.issue31707@psf.upfronthosting.co.za>
Message-ID: <1507280588.27.0.213398074469.issue31707@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this is way beyond the scope of the current fractions module. I'd suggest putting something on PyPI as a proof of concept.

Given the negative response from other core developers, I'm going to close here.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31707>
_______________________________________

From report at bugs.python.org  Fri Oct  6 05:03:39 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 09:03:39 +0000
Subject: [issue31596] expose pthread_getcpuclockid in time module
In-Reply-To: <1506450794.16.0.162056328414.issue31596@psf.upfronthosting.co.za>
Message-ID: <1507280619.65.0.213398074469.issue31596@psf.upfronthosting.co.za>


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

Thank you Benjamin, buildots are back to green :-)

I prefer the new unit test which only tests pthread_getcpuclockid() clock and not make any assumption on the link between this clock and CLOCK_THREAD_CPUTIME_ID.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31596>
_______________________________________

From report at bugs.python.org  Fri Oct  6 05:43:00 2017
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Fri, 06 Oct 2017 09:43:00 +0000
Subject: [issue31711] ssl.SSLSocket.send(b"") fails
Message-ID: <1507282980.19.0.213398074469.issue31711@psf.upfronthosting.co.za>


New submission from J?rn Heissler <launchpad at joern.heissler.de>:

Traceback (most recent call last):
  File "client.py", line 10, in <module>
    conn.send(b'')
  File "/usr/lib/python3.6/ssl.py", line 941, in send
    return self._sslobj.write(data)
  File "/usr/lib/python3.6/ssl.py", line 642, in write
    return self._sslobj.write(data)
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2074)

This error is not what I expected. I expected a noop instead.

My guess is, that python calls SSL_write (3.6 branch, _ssl.c:2038) with that empty buffer.
The manpage states: "When calling SSL_write() with num=0 bytes to be sent the behaviour is undefined."

This undefined behaviour should either be documented in python, or defined to either raise an exception (ValueError?) or defined as a noop. I'd prefer the latter.

----------
assignee: christian.heimes
components: SSL
files: client.py
messages: 303810
nosy: christian.heimes, joernheissler
priority: normal
severity: normal
status: open
title: ssl.SSLSocket.send(b"") fails
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47194/client.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31711>
_______________________________________

From report at bugs.python.org  Fri Oct  6 05:49:19 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 06 Oct 2017 09:49:19 +0000
Subject: [issue31165] null pointer deref and segfault in list_slice
 (listobject.c:455)
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507283359.28.0.213398074469.issue31165@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Here is some similar code that crashes for the same reasons:

# create a circular reference with a malicious __del__().
class A:
    def __del__(*args):
        del list1[0]
circ_ref_obj = A()
circ_ref_obj._self = circ_ref_obj

list1 = [None]
list2 = []
del circ_ref_obj
while len(list2) < 10000:
    list2.append(list1[:])

IIUC, list_slice() first finds the boundaries of the slice and its length, and
then calls PyList_New().
But PyList_New() might call PyObject_GC_New(), which eventually causes a call
to _PyObject_GC_Alloc(), which might call collect_generations(), which causes
the malicious __del__() to run.
After __del__() empties the list, list_slice() continues to run, but the list's
boundaries it found earlier are now invalid, and so it tries to read the first
element in the now empty list, and crashes.


Maybe we should prevent collection of garbage with circular references (that
has __del__() or weakref callbacks) from PyObject_GC_New()?

ISTM there might be a lot of places with similar issues. (e.g. if we replace
'list2.append(list1[:])' with 'list2.append(list1[::-1])', we get a crash in
list_subscript()).
So i think that fixing each of them would be harder and might even introduce a
regression in performance.

----------
nosy: +Oren Milman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 05:52:36 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 06 Oct 2017 09:52:36 +0000
Subject: [issue31092] multiprocessing.Manager() race condition
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507283556.19.0.213398074469.issue31092@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Davin and Antoine, i added you to the nosy list because you are listed
as multiprocessing experts :)

----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Fri Oct  6 05:58:50 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 06 Oct 2017 09:58:50 +0000
Subject: [issue31165] null pointer deref and segfault in list_slice
 (listobject.c:455)
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507283930.72.0.213398074469.issue31165@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Oh, and calls to PyObject_GC_NewVar() might also cause similar issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 06:45:57 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Oct 2017 10:45:57 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1507286757.33.0.213398074469.issue25658@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This has been merged now: https://github.com/python/cpython/commit/731e18901484c75b60167a06a0ba0719a6d4827d

Thank you for the PEP & implementation! :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Oct  6 07:39:10 2017
From: report at bugs.python.org (l4mer)
Date: Fri, 06 Oct 2017 11:39:10 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
Message-ID: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>


New submission from l4mer <janusz.dziedzic at gmail.com>:

I am using ssh mux + authorized key. So can exectute commands without passwod.

1. disconnect mux by: ssh user at localhost -O exit
2. run simple script
import subprocess

if __name__ == '__main__':
    cmd = ["ssh", "user at localhost", "id"]
    try:
        buf = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
    except subprocess.CalledProcessError as e:
        buf = e.output
3. This always hang in read(3,
fcntl(3, F_GETFL)                       = 0 (flags O_RDONLY)
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f036b5f1000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
munmap(0x7f036b5f1000, 4096)            = 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "uid=0(", 6)                    = 6
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "root) ", 6)                    = 6
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "gid=0(r", 7)                   = 7
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "oot) gro", 8)                  = 8
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "ups=0(roo", 9)                 = 9
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "t)\n", 10)                     = 3
read(3, 0x7f036b480653, 7)              = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21620, si_status=0, si_utime=1, si_stime=0} ---
read(3,

4. After ctr+c
read(3, ^CProcess 21619 detached
 <detached ...>
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    buf = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
  File "/usr/lib/python2.7/subprocess.py", line 567, in check_output
    output, unused_err = process.communicate()
  File "/usr/lib/python2.7/subprocess.py", line 791, in communicate
wigig at wigig-Latitude-E5270:~$     stdout = _eintr_retry_call(self.stdout.read)
  File "/usr/lib/python2.7/subprocess.py", line 476, in _eintr_retry_call
    return func(*args)

BTW, when MUX is created it always works.

----------
messages: 303815
nosy: l4mer
priority: normal
severity: normal
status: open
title: subprocess with stderr=subprocess.STDOUT hang
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Fri Oct  6 09:11:37 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Oct 2017 13:11:37 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507295497.1.0.213398074469.issue31712@psf.upfronthosting.co.za>


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

Given the title, are you saying that it works if you omit the stderr=subprocess.STDOUT?  At the beginning you say you are using an authorized key and mux so you don't need to enter a password, and at the end you say it works fine if the MUX is created.  So that sounds like the failure is when you are trying to establish the first connection.  Perhaps the problem is that the subprocess doesn't have access to your key for some reason, and therefore ssh is prompting for a password?

----------
nosy: +gregory.p.smith, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Fri Oct  6 09:23:46 2017
From: report at bugs.python.org (l4mer)
Date: Fri, 06 Oct 2017 13:23:46 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507296226.79.0.213398074469.issue31712@psf.upfronthosting.co.za>


l4mer <janusz.dziedzic at gmail.com> added the comment:

yes, works perfectly when omit stderr=subprocess.STDOUT no matter if mux exists.
Also from bash: ssh user at locahost id always works.

Problem exists only when stderr=subprocess.STDOUT and no MUX yet.
BTW, first connection create a MUX - but this seems to be an unimportant detail.

This is 100% reproducible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Fri Oct  6 09:35:28 2017
From: report at bugs.python.org (l4mer)
Date: Fri, 06 Oct 2017 13:35:28 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507296928.2.0.213398074469.issue31712@psf.upfronthosting.co.za>


l4mer <janusz.dziedzic at gmail.com> added the comment:

BTW, when you will check point 3 you will notice that we already read id output, so command execute correctly: "uid=0(root" ...
And problem is after that.

Steps I reproduce this issue:
- standard user have keys and
 in ~/.ssh/config
Host *
   ControlMaster auto
   ControlPath /tmp/ssh-%r@%h:%p
   ControlPersist yes

- on root (authorized_key installed)
cat ~user/.ssh/id_rsa.pub >> ~root/.ssh/authorized_keys

- on user, reproduce
ssh root at localhost -O exit # destroy mux
strace python test.py # script I paste before

I hit this problem of few machines, with different linux kernels ...
Seems like generic problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Fri Oct  6 09:37:29 2017
From: report at bugs.python.org (matthewlweber)
Date: Fri, 06 Oct 2017 13:37:29 +0000
Subject: [issue31713] python3 python-config script generates invalid includes
Message-ID: <1507297049.36.0.213398074469.issue31713@psf.upfronthosting.co.za>


New submission from matthewlweber <matthew.weber at rockwellcollins.com>:

Related to https://bugs.python.org/issue22907

If building in a path that starts with /usr, the includedir=$(echo "@includedir@" | sed "s#^$prefix_build#$prefix_real#") assignment in the python-config.sh ends up having the path it processes ran through a path substitution once before this line is executed because the @includedir@ in the python-config.sh.in is set to the string '${prefix}/include'.  ${prefix} is assigned just above includedir in python-config.sh to prefix=$(echo "$prefix_build" | sed "s#^$prefix_build#$prefix_real#")

I believe we need to update the includedir to 

includedir=$(echo "@includedir@")

Or rename the prefix variable in python-config.sh so that there isn't a naming conflict if a string is passed in via @includedir@ with that variable.

Without fixing this you end up with multiple /usr substitutions in the includedir string, each replaced with the real path.  ie resulting in an invalid path.

----------
components: Cross-Build
messages: 303819
nosy: Alex.Willmer, matthewlweber
priority: normal
severity: normal
status: open
title: python3 python-config script generates invalid includes
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31713>
_______________________________________

From report at bugs.python.org  Fri Oct  6 09:53:49 2017
From: report at bugs.python.org (Albert-Jan Nijburg)
Date: Fri, 06 Oct 2017 13:53:49 +0000
Subject: [issue7167] Smarter FTP passive mode
In-Reply-To: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
Message-ID: <1507298029.37.0.213398074469.issue7167@psf.upfronthosting.co.za>


Albert-Jan Nijburg <albertjan at trinket.io> added the comment:

I understand the standpoint that the server is configured incorrectly, and I see why this might not be the best solution to the problem. 

But not everyone owns the ftp server they're connecting to. And the `EPSV` command often doesn't include the ipaddress, so many ftp clients are now using `EPSV` to circumvent the problem of the ip address and the dns address not matching up.

Would it not be sensible to give users the option to use just `EPSV` so people can connect to incorrectly configured ftp servers. Although this can't be a massive issue for people, because I'd expect this bug to be a bit more active. 

Curl for example defaults to EPSV and then falls back to PASV when it's not supported by the server. The ftp client in macos also defaults to EPSV. I'm not sugesting we do that, but it would be nice if we could tell the ftplib to use EPSV without it being a ipv6 address. 

In our specific situation, we have an ftp server that has a public and a private endpoint on different ip addresses, and the ftp server is configured to use the public ip address, but if we want to access in internally we need to use the internal host and ip address. This causes `ftplib` not to work, because the ips don't line up. 

We currently monkey patch ftplib to use `EPSV`, but it does state that you need to use EPSV when you connect with ipv6 it doesn't say you can't use it when you use ipv4.

----------
nosy: +Albert-Jan Nijburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7167>
_______________________________________

From report at bugs.python.org  Fri Oct  6 09:54:11 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 Oct 2017 13:54:11 +0000
Subject: [issue31693] Document Py_GETENV
In-Reply-To: <1507132975.16.0.213398074469.issue31693@psf.upfronthosting.co.za>
Message-ID: <1507298051.84.0.213398074469.issue31693@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31693>
_______________________________________

From report at bugs.python.org  Fri Oct  6 10:20:31 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 14:20:31 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507299631.4.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

test_regrtest is not the single test failing when COUNT_ALLOCS is defined. Not least than 12 tests are failing.

In Python 3, many tests were fixed by skipping them if COUNT_ALLOCS is defined: commit a793037d803abf098d172f686e2b95d27863c54d of bpo-19527.

Since Python 3.6, even if COUNT_ALLOCS is defined, statistics are no more dumped by default, but only if -X showalloccount is defined: commit 7e160ce356036bccda2608d9ee10bfe276dfa97a of bpo-23034. Moreover, statitics are now written into stderr rather than stdout.

----------
nosy: +haypo
title: Test `test_huntrleaks` fails in debug build with COUNT_ALLOCS -> [2.7] Test `test_huntrleaks()` of test_regrtest fails in debug build with COUNT_ALLOCS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 10:22:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 14:22:12 +0000
Subject: [issue31714] Improve re documentation
Message-ID: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR improves the documentation of re module and Regular Expression HOWTO.

* Clarify the effect of the LOCALE flag.

* Remove outdated statements.

* Add an example of escaping a replacement string.

* Add or correct some references.

* Improve and fix a formatting.

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 303822
nosy: akuchling, barry, docs at python, ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve re documentation
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 10:24:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 14:24:31 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507299871.15.0.213398074469.issue31714@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3878

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:05:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 15:05:28 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507302328.72.0.213398074469.issue31714@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:06:26 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 15:06:26 +0000
Subject: [issue24896] It is undocumented that re.UNICODE and re.LOCALE affect
 re.IGNORECASE
In-Reply-To: <1439987891.31.0.547960058443.issue24896@psf.upfronthosting.co.za>
Message-ID: <1507302386.54.0.213398074469.issue24896@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I tried to correct the documentation in issue31714.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24896>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:06:33 2017
From: report at bugs.python.org (Bradley Meck)
Date: Fri, 06 Oct 2017 15:06:33 +0000
Subject: [issue31715] Add mimetype for extension .mjs
Message-ID: <1507302393.84.0.213398074469.issue31715@psf.upfronthosting.co.za>


New submission from Bradley Meck <bradley.meck at gmail.com>:

I propose to add a mapping of file extension .mjs to mime type "text/javascript".
The "text/javascript" MIME is registered in https://www.iana.org/assignments/media-types, was moved to *should* as the MIME in HTML ( https://github.com/whatwg/html/pull/3096), and is being updated by https://datatracker.ietf.org/doc/draft-bfarias-javascript-mjs/

This extension is being used by Node.js for support of ECMAScript Modules (ESM).

----------
components: Library (Lib)
messages: 303824
nosy: Bradley Meck
priority: normal
severity: normal
status: open
title: Add mimetype for extension .mjs
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31715>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:11:22 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Fri, 06 Oct 2017 15:11:22 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507302682.57.0.213398074469.issue31714@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

I was looking at your changes and got myself in a muddle. What is you rational for when you use ``[character or string]`` versus ``'[character or string]``? You seem to be creating consistency there, but I cannot quite see the rules you are aiming for!

----------
nosy: +Henk-Jaap Wagenaar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:19:35 2017
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Oct 2017 15:19:35 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507303175.42.0.213398074469.issue31714@psf.upfronthosting.co.za>


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

ISTM that ``x`` is used when x is a regex or regex metachar, whereas ``'x'`` is used when 'x' is a string.  I find this distinction reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:26:29 2017
From: report at bugs.python.org (Mor Haviv)
Date: Fri, 06 Oct 2017 15:26:29 +0000
Subject: [issue31716] os.path.isdir returns true for dots
Message-ID: <1507303589.7.0.213398074469.issue31716@psf.upfronthosting.co.za>


New submission from Mor Haviv <morhaviv14 at gmail.com>:

I uploaded this as a question on Stack Overflow and I suspect it might be a bug. Here is the link for the Stack Overflow question: https://stackoverflow.com/questions/46608731/python-os-path-isdir-returns-true-for-dots/46608842#46608842

The problem itself (copied from what I uploaded on Stack Overflow):

I'm programming my own shell in python. Right now I'm trying to implement the `cd` command to my shell.

The function that performs this command has several variables:

`self.current_dir = "C:\\"` - The default value, it changes depends on the user's input using the cd command

`dir = "..."` - The requested directory that the user types. "..." is an example for an input that causes the problem.

Here is my code:

    def command_cd(self, dir):
        if os.path.isdir(self.shell.current_dir + dir):
            self.shell.current_dir = self.shell.current_dir + dir + "\\"

The problem is that for some strange reason, `os.path.isdir(self.shell.current_dir + dir)` returns `True` when the user types dots (Just like the example inputs for the variables which I gave above). 

The problem occurs even if you change the amount of dots (even above 5 dots) and I really have no idea what causes it.

There's obviously no folder named `...` or anything like it.


**If my problem isn't clear enough please comment and I'll edit it**

----------
components: Windows
messages: 303827
nosy: morha13, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.isdir returns true for dots
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31716>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:27:13 2017
From: report at bugs.python.org (Bradley Meck)
Date: Fri, 06 Oct 2017 15:27:13 +0000
Subject: [issue31715] Add mimetype for extension .mjs
In-Reply-To: <1507302393.84.0.213398074469.issue31715@psf.upfronthosting.co.za>
Message-ID: <1507303633.2.0.213398074469.issue31715@psf.upfronthosting.co.za>


Change by Bradley Meck <bradley.meck at gmail.com>:


----------
keywords: +patch
pull_requests: +3879
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31715>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:28:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 15:28:02 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507303682.79.0.213398074469.issue31692@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Commit a793037d803abf098d172f686e2b95d27863c54d is not related to this issue. It skips the tests that were failed due to other side effect of COUNT_ALLOCS -- it makes type immortal. This is not a problem in 2.7 since all types are immortal in 2.7.

But there is other patch in issue19527: 00141-fix-tests_with_COUNT_ALLOCS-v5.patch. It was not committed since issue23034 provided better solution. You can try to backport it to 2.7, but this will just complicate the testing code for almost no benefit. Nobody wanted to do this. It was a decision to ignore this issue in Python 3.5 and earlier.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:40:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 15:40:34 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507304434.4.0.213398074469.issue31714@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is explained in the documentation:

"""
(In the rest of this
section, we'll write RE's in ``this special style``, usually without quotes, and
strings to be matched ``'in single quotes'``.)
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:42:58 2017
From: report at bugs.python.org (Mor Haviv)
Date: Fri, 06 Oct 2017 15:42:58 +0000
Subject: [issue31716] os.path.isdir returns true for dots
In-Reply-To: <1507303589.7.0.213398074469.issue31716@psf.upfronthosting.co.za>
Message-ID: <1507304578.92.0.213398074469.issue31716@psf.upfronthosting.co.za>


Change by Mor Haviv <morhaviv14 at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31716>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:43:19 2017
From: report at bugs.python.org (Mor Haviv)
Date: Fri, 06 Oct 2017 15:43:19 +0000
Subject: [issue31716] os.path.isdir returns true for dots
In-Reply-To: <1507303589.7.0.213398074469.issue31716@psf.upfronthosting.co.za>
Message-ID: <1507304599.4.0.213398074469.issue31716@psf.upfronthosting.co.za>


Change by Mor Haviv <morhaviv14 at gmail.com>:


----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31716>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:53:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 15:53:05 +0000
Subject: [issue31165] null pointer deref and segfault in list_slice
 (listobject.c:455)
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507305185.84.0.213398074469.issue31165@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oh, you are right Oren. Seems this is the only solution.

----------
nosy: +haypo, lemburg, pitrou, serhiy.storchaka, tim.peters, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:53:09 2017
From: report at bugs.python.org (Phillip)
Date: Fri, 06 Oct 2017 15:53:09 +0000
Subject: [issue31717] Socket documentation threading misstep?
Message-ID: <1507305189.16.0.213398074469.issue31717@psf.upfronthosting.co.za>


New submission from Phillip <phillip at infiniteautomation.com>:

Very small, but,

https://docs.python.org/2/howto/sockets.html
https://docs.python.org/3/howto/sockets.html

have :
while True:
    # accept connections from outside
    (clientsocket, address) = serversocket.accept()
    # now do something with the clientsocket
    # in this case, we'll pretend this is a threaded server
    ct = client_thread(clientsocket)
    ct.run()

and for some reason I really want it to be ct.start()

----------
assignee: docs at python
components: Documentation
messages: 303831
nosy: apoplexy, docs at python
priority: normal
severity: normal
status: open
title: Socket documentation threading misstep?
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31717>
_______________________________________

From report at bugs.python.org  Fri Oct  6 11:55:11 2017
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 06 Oct 2017 15:55:11 +0000
Subject: [issue31716] os.path.isdir returns true for dots
In-Reply-To: <1507303589.7.0.213398074469.issue31716@psf.upfronthosting.co.za>
Message-ID: <1507305311.05.0.213398074469.issue31716@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

This is standard Windows API behavior for the final path component. A single dot component means the current directory. Two dots means the parent directory. More than two dots and/or trailing spaces, gets reduced to a single dot, meaning the current directory. For example:

    >>> os.path.abspath('.')
    'C:\\Temp'
    >>> os.path.abspath('..')
    'C:\\'
    >>> os.path.abspath('...')
    'C:\\Temp'
    >>> os.path.abspath('... ... ...')
    'C:\\Temp'

Specifically, os.path.isdir is implemented as nt._isdir, which calls WinAPI GetFileAttributes to check for FILE_ATTRIBUTE_DIRECTORY, which in turn calls the NT system function NtQueryAttributesFile. 

GetFileAttributes has to translate the DOS path to an NT kernel path. In the kernel, none of this "." business exists. The kernel doesn't even have a concept of a working directory. Depending on your Windows version, it might call the runtime library function RtlDosPathNameToNtPathName_U_WithStatus to convert the path to a native OBJECT_ATTRIBUTES record. The first step is to normalize the path via RtlGetFullPathName_Ustr, which is what the Windows API GetFullPathName function calls like in the above abspath() examples.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31716>
_______________________________________

From report at bugs.python.org  Fri Oct  6 12:00:34 2017
From: report at bugs.python.org (Brian Ward)
Date: Fri, 06 Oct 2017 16:00:34 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507305634.02.0.213398074469.issue31714@psf.upfronthosting.co.za>


Brian Ward <bri at aem7.net> added the comment:

In re.rst, the instances of "Correcsponds the" should be "Corresponds to the" and "Doesn't have correcsponding inline flag" should be "No corresponding inline flag."

----------
nosy: +Brian Ward

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Fri Oct  6 12:37:18 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Oct 2017 16:37:18 +0000
Subject: [issue31717] Socket documentation threading misstep?
In-Reply-To: <1507305189.16.0.213398074469.issue31717@psf.upfronthosting.co.za>
Message-ID: <1507307838.24.0.213398074469.issue31717@psf.upfronthosting.co.za>


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

Based on the paragraph following the example, I don't think client_thread is a threading.Thread, and 'run' is meant to be a generic representation of a possible API.  Since Threads do have a 'run' method, this is certainly potentially confusing.  Maybe we should change it to 'start_thread' or something like that?

----------
nosy: +r.david.murray
versions:  -Python 3.4, Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31717>
_______________________________________

From report at bugs.python.org  Fri Oct  6 12:44:05 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Oct 2017 16:44:05 +0000
Subject: [issue31717] Socket documentation threading misstep?
In-Reply-To: <1507305189.16.0.213398074469.issue31717@psf.upfronthosting.co.za>
Message-ID: <1507308245.67.0.213398074469.issue31717@psf.upfronthosting.co.za>


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

Or maybe instead of client_handler/run, it should be something like handle_client_asynchronously(clientsocket).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31717>
_______________________________________

From report at bugs.python.org  Fri Oct  6 12:47:19 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 06 Oct 2017 16:47:19 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507308439.91.0.213398074469.issue31558@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Alright Python people, I don't see anybody being against the idea on the thread.  Can we get a review of the linked PR?  I don't think it would be good form for me to accept it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Fri Oct  6 12:57:36 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Oct 2017 16:57:36 +0000
Subject: [issue31666] Pandas_datareader Error Message - ModuleNotFoundError:
 No module named 'pandas_datareader' with module in folder
Message-ID: <1507309056.54.0.213398074469.issue31666@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Hello!  Your bug report gives very little information for us to help you.  Can you give details such as: your environement / setup, your code, expected result and full error message?

https://devguide.python.org/tracker/#reporting-an-issue

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31666>
_______________________________________

From report at bugs.python.org  Fri Oct  6 13:00:05 2017
From: report at bugs.python.org (Phillip)
Date: Fri, 06 Oct 2017 17:00:05 +0000
Subject: [issue31717] Socket documentation threading misstep?
In-Reply-To: <1507308245.67.0.213398074469.issue31717@psf.upfronthosting.co.za>
Message-ID: <CAHg6k98CVqTf6QjbNuaLCAYkvjD4zraSunHwhAwkdWt6L7Jneg@mail.gmail.com>


Phillip <phillip at infiniteautomation.com> added the comment:

I could definitely understand that. After all, if it's slightly askew (or
strikes some as such) it forces critical thinking, which is good. I didn't
think calling run() was indicative of the three likely pathways to handle
the client socket in the following paragraph.

I'm indifferent, I just saw something so I said something, but ultimately I
think you guys do a tremendous job keeping this documentation good.

Thanks,

On Fri, Oct 6, 2017 at 10:44 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Or maybe instead of client_handler/run, it should be something like
> handle_client_asynchronously(clientsocket).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31717>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31717>
_______________________________________

From report at bugs.python.org  Fri Oct  6 13:06:28 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 06 Oct 2017 17:06:28 +0000
Subject: [issue31700] one-argument version for Generator.typing
In-Reply-To: <1507192517.86.0.213398074469.issue31700@psf.upfronthosting.co.za>
Message-ID: <1507309588.53.0.213398074469.issue31700@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

You can use Iterator type, for example this works in mypy (didn't test in other type checkers):

  def f() -> Iterator[int]:
      yield 42

In case you want annotate something specifically as Generator[int, None, None] (for example to use its .close() method), then you can create a generic alias:

  T = TypeVar('T')
  Gen = Generator[T, None, None]

  def f() -> Gen[int]:
      ...

this is supported by mypy as well.

----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31700>
_______________________________________

From report at bugs.python.org  Fri Oct  6 13:48:03 2017
From: report at bugs.python.org (matthewlweber)
Date: Fri, 06 Oct 2017 17:48:03 +0000
Subject: [issue31713] python3 python-config script generates invalid includes
In-Reply-To: <1507297049.36.0.213398074469.issue31713@psf.upfronthosting.co.za>
Message-ID: <1507312083.07.0.213398074469.issue31713@psf.upfronthosting.co.za>


Change by matthewlweber <matthew.weber at rockwellcollins.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file47195/0029-python-config.sh-don-t-reassign-prefix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31713>
_______________________________________

From report at bugs.python.org  Fri Oct  6 13:54:19 2017
From: report at bugs.python.org (reidfaiv)
Date: Fri, 06 Oct 2017 17:54:19 +0000
Subject: [issue31591] Closing socket raises AttributeError:
 'collections.deque' object has no attribute '_decref_socketios'
In-Reply-To: <1506423868.44.0.968850601385.issue31591@psf.upfronthosting.co.za>
Message-ID: <1507312459.38.0.213398074469.issue31591@psf.upfronthosting.co.za>


reidfaiv <reid.faiv at null.net> added the comment:

I will withdraw this bug report. I am unable to isolate that issue, hence I can not confirm if this is purely Python crash or caused by some extension. It looks memory corruption to me as segfault moves around and produces different stack traces - the network code is probably just a victim.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31591>
_______________________________________

From report at bugs.python.org  Fri Oct  6 14:03:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 18:03:24 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507313004.93.0.213398074469.issue31558@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about msg302790?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Fri Oct  6 14:09:48 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 06 Oct 2017 18:09:48 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
Message-ID: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

Given an uninitialized IncrementalNewlineDecoder:
uninitialized = io.IncrementalNewlineDecoder.__new__(io.IncrementalNewlineDecoder)

each of the following calls would raise a SystemError ('null argument to
internal routine'):
uninitialized.getstate()
uninitialized.setstate((b'foo', 0))
uninitialized.reset()

In contrast, the following call would raise a ValueError
('IncrementalNewlineDecoder.__init__ not called'):
uninitialized.decode(b'bar')

ISTM that getstate(), setstate(), and reset() should have the same behavior as
decode(). (Though i think that including the actual type name in the error
message would be better, as it could be a subclass of IncrementalNewlineDecoder).

----------
components: IO
messages: 303842
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: some methods of uninitialized io.IncrementalNewlineDecoder objects raise SystemError
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Fri Oct  6 14:52:51 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Oct 2017 18:52:51 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507315971.95.0.213398074469.issue31655@psf.upfronthosting.co.za>


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

After reading the doc entry for SimpleNamespace, I see running 'SimpleNamespace(**{0:0})' as a bug because doing so results in an object than contradicts the doc.

1. "A simple object subclass that provides attribute access to its namespace, as well as a meaningful repr. Unlike ... you can ... delete attributes."

But, after 'sn = SimpleNamespace(**{0:0})', sn.0 is a SyntaxError and getattr(sn, 0) raises 'TypeError: getattr(): attribute name must be string'.  As already noted, the 'attribute' does not appear in repr(sn).  'del sn.0' and 'delattr(sn, 0)' also fail.  If this is a feature, it is extremely buggy.

2. "The type is roughly equivalent to the following code:"

class SimpleNamespace:
    def __init__(self, **kwargs):
        self.__dict__.update(kwargs)

    def __repr__(self):
        keys = sorted(self.__dict__)
        items = ("{}={!r}".format(k, self.__dict__[k]) for k in keys)
        return "{}({})".format(type(self).__name__, ", ".join(items))

    def __eq__(self, other):
        return self.__dict__ == other.__dict__

With this definition, SimpleNamespace(**{0:0}) raises TypeError.  To me, running versus raising is outside the bounds of 'roughly equivalent'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:04:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 19:04:41 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507316681.54.0.213398074469.issue31672@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Another solution (works in 3.6 too): set idpattern to r'(?-i:[_a-zA-Z][_a-zA-Z0-9]*)'.

This looks pretty weird, setting the re.IGNORECASE flag and then unsetting it. But it works, and don't break the user code that changes idpattern without changing flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:13:14 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Oct 2017 19:13:14 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507317194.16.0.213398074469.issue31680@psf.upfronthosting.co.za>


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

pythoninfo seems like the right place.  It is publicly readable.  We just reserved the right to change it in any release as needed.  (This actually is useful to other users also as long as they know.) #15037 was originally filed for 3.4 and is currently marked for 3.6.  Backporting this to 3.6 will allow a 3.6 fix for #15037.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:32:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 19:32:24 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507318344.94.0.213398074469.issue31655@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3881
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:33:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 19:33:42 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507318422.8.0.213398074469.issue31655@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:38:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 19:38:54 +0000
Subject: [issue31680] Expose curses library name and version on Python level
In-Reply-To: <1507059542.78.0.213398074469.issue31680@psf.upfronthosting.co.za>
Message-ID: <1507318734.25.0.213398074469.issue31680@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No need to backport this to 3.6. The test in 3.6 can be skipped on OpenBSD, independently from the ncurses version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31680>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:40:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 19:40:21 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1507318821.63.0.213398074469.issue31718@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is IncrementalNewlineDecoder subclassable?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:58:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 19:58:09 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507319889.11.0.213398074469.issue31692@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3882
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 15:58:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 19:58:09 +0000
Subject: [issue19527] Test failures with COUNT_ALLOCS
In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za>
Message-ID: <1507319889.21.0.00913614298617.issue19527@psf.upfronthosting.co.za>


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


----------
pull_requests: +3883

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

From report at bugs.python.org  Fri Oct  6 16:02:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:02:02 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507320122.12.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

I wrote PR 3910 to modify COUNT_ALLOCS: alllcations statistics are now written into stderr, rather than stdout.

The PR contains also changes to fix tests with COUNT_ALLOCS. I'm not sure about this part of the PR. I would prefer to not dump statistics by default, and add a new option to enable it.

I don't know if we can easily implement "-X showalloccount", since Python 2.7 doesn't have sys._xoptions. Maybe we could use a new environment variable instead: PYTHONSHOWALLOCCOUNT=1?

I would prefer to add a new option instead of having to patch so many unit tests:

haypo at selma$ git diff 2.7.. --stat
 Lib/json/tests/test_tool.py                                                 |  8 ++++++--
 Lib/test/support/__init__.py                                                |  3 +++
 Lib/test/test_abc.py                                                        |  2 ++
 Lib/test/test_gc.py                                                         |  4 +++-
 Lib/test/test_hash.py                                                       |  2 +-
 Lib/test/test_module.py                                                     |  3 ++-
 Lib/test/test_multiprocessing.py                                            |  4 +++-
 Lib/test/test_regrtest.py                                                   |  1 +
 Lib/test/test_subprocess.py                                                 | 17 +++++++++++++++++
 Lib/test/test_sys.py                                                        | 21 +++++++++++++++------
 Lib/test/test_threading.py                                                  | 11 ++++++++---
 Lib/test/test_tools.py                                                      | 10 +++++++---
 Lib/test/test_warnings.py                                                   |  4 ++++
 Lib/test/test_weakref.py                                                    |  1 +
 Misc/NEWS.d/next/Core and Builtins/2017-10-06-21-56-47.bpo-31692.osJuVJ.rst |  2 ++
 Python/pythonrun.c                                                          |  2 +-
 16 files changed, 76 insertions(+), 19 deletions(-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:09:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:09:19 +0000
Subject: [issue31165] null pointer deref and segfault in list_slice
 (listobject.c:455)
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507320559.68.0.213398074469.issue31165@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3884
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:10:33 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:10:33 +0000
Subject: [issue31165] null pointer deref and segfault in list_slice
 (listobject.c:455)
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507320633.9.0.213398074469.issue31165@psf.upfronthosting.co.za>


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

> Oh, you are right Oren. Seems this is the only solution.

There are other solutions. I wrote PR 3911 which checks if the list size changed after PyList_New(). If it's the case, a RuntimeError exception is raised.

We implemented similar checks in the dict type, if the dict is mutated during iterating on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:12:48 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:12:48 +0000
Subject: [issue31165] null pointer deref and segfault in list_slice
 (listobject.c:455)
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507320768.39.0.213398074469.issue31165@psf.upfronthosting.co.za>


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

"Maybe we should prevent collection of garbage with circular references (that has __del__() or weakref callbacks) from PyObject_GC_New()?"

That would be a major change in the garbage collector. I would prefer to not touch the GC, any change can introduce a complex regression.

Running the GC when an object is allocated makes sense to me. It's to reclaim memory, and prevent a MemoryError which would only be caused by "missed GC".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:13:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:13:27 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507320807.23.0.213398074469.issue31165@psf.upfronthosting.co.za>


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


----------
title: null pointer deref and segfault in list_slice (listobject.c:455) -> list_slice() does crash if the list is mutated indirectly by PyList_New()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:19:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 20:19:52 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507321192.67.0.213398074469.issue31692@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:21:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 20:21:23 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507321283.26.0.213398074469.issue31692@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you going to backport also -X showrefcount?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:24:33 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:24:33 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507321473.4.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

My colleague Iryna Shcherbina came to me with this issue. I'm not sure that we really need to support COUNT_ALLOCS. But strangely, it seems simpler to fix bugs rather than guessing if users like this debug mode or not :-)

There are different ways to fix tests to make them passing with COUNT_ALLOCS. As I wrote, I would prefer to add a new Python 2.7 option to explicitly asks to dump allocations statistics: add a new PYTHONSHOWALLOCCOUNT=1 environment variable for example.

What do you think Serhiy? Do you prefer to decorate many 2.7 tests to skip them if COUNT_ALLOCS is used, or to add a new option?

I should try to implement -X showalloccount :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:33:32 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 06 Oct 2017 20:33:32 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1507322012.9.0.213398074469.issue31718@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Yes, although i don't know if there are usecases for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:35:01 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:35:01 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
Message-ID: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>


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

On the s390x architecture, the test_regrtest.test_crashed() fails because Python doesn't crash.

test.support._crash_python() calls ctypes.string_at(0) to crash Python. In debug mode, ctypes.string_at(0) fails with an assertion error and the process is killed with the SIGABRT signal. In release mode, ctypes.string_at(0) returns an empty string but doesn't crash.

Attached PR adds a new _testcapi._read_null() function which does crash in a reliable way on s390x and x86 :-) The function uses the C "volatile" keyword to prevent compiler optimizations. I copied the code from my faulthandler._read_null() function in the master branch which was battle tested. It does crash on all platforms... except of AIX.

----------
components: Tests
messages: 303854
nosy: haypo
priority: normal
severity: normal
status: open
title: [2.7] test_regrtest.test_crashed() fails on s390x
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:36:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:36:28 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507322188.94.0.213398074469.issue31719@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3885
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:36:32 2017
From: report at bugs.python.org (Iryna Shcherbina)
Date: Fri, 06 Oct 2017 20:36:32 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507322192.79.0.213398074469.issue31692@psf.upfronthosting.co.za>


Iryna Shcherbina <shcherbina.iryna at gmail.com> added the comment:

> I don't know if we can easily implement "-X showalloccount", since
> Python 2.7 doesn't have sys._xoptions. Maybe we could use a new
> environment variable instead: PYTHONSHOWALLOCCOUNT=1?


That is how it is bypassed in Fedora Py2 builds currently. I am attaching the patch we use.

----------
Added file: https://bugs.python.org/file47196/00125-less-verbose-COUNT_ALLOCS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:39:01 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:39:01 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507322341.03.0.213398074469.issue31719@psf.upfronthosting.co.za>


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


----------
nosy: +cstratak, ishcherb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:43:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 20:43:42 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507322622.77.0.213398074469.issue31165@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is different case than mutating a dict while iterate it. In this case the failure is caused by GC, and it is always hard to handle such issues. In case of a dict you can just copy it before iterating. But what to do with RuntimeError from slicing a list if copying a list is vulnerable to the same issue?

The example of yet one solution you can see in dict_keys() in dictobject.c. I always wondered why this code is needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:46:00 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:46:00 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507322760.81.0.213398074469.issue31165@psf.upfronthosting.co.za>


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

> This is different case than mutating a dict while iterate it. In this case the failure is caused by GC, and it is always hard to handle such issues. In case of a dict you can just copy it before iterating. But what to do with RuntimeError from slicing a list if copying a list is vulnerable to the same issue?

This issue was found by fuzzing with weird destructor. I don't think that anyone will hit the bug with "normal" code in the wild. Otherwise, we would have get a bug report before this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:47:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 20:47:27 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507322847.36.0.213398074469.issue31692@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I left this on to Benjamin, the RM of Python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 16:58:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Oct 2017 20:58:45 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507323525.52.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

Serhiy:
> Do you going to backport also -X showrefcount?

I see -X as a Python3 only thing. If I have to choose, I would prefer to add a new environment variable, since it's more in the "Python2 style".

Iryna:
> That is how it is bypassed in Fedora Py2 builds currently. I am attaching the patch we use.

Oh, nice to see that we get the same idea: opt-in environment variable.

I'm unhappy with the variable name: PYTHONDUMPCOUNTS seems too generic IMHO :-(

I prefer "PYTHONSHOWALLOCCOUNT" since it's closer to Python 3 "-X showalloccount" option, and "alloc" mentions that they are counters on allocations. Not just "random" counters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Fri Oct  6 17:00:09 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 21:00:09 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1507323609.23.0.213398074469.issue31718@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is other issues with IncrementalNewlineDecoder.__init__ -- it leaks references when called repeatedly.

The simplest solution of both issues will be moving the initialization to the new method. But this class looks designed for subclassing, and this can break subclasses that change arguments before passing them to the superclass' constructor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Fri Oct  6 17:03:11 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Oct 2017 21:03:11 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507323791.43.0.213398074469.issue31165@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Or the bug is so hard for reproducing, that nobody had enough information for reporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Fri Oct  6 18:02:05 2017
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 06 Oct 2017 22:02:05 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1507327325.13.0.213398074469.issue31340@psf.upfronthosting.co.za>


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

I have Visual Studio 2015 and Visual Studio 2017 Community editions with latest patches installed.

Building a minimal C extension on Python 3.6.3 with distutils now uses MSVC 14.11.25503. That is unexpected.

When building complex extensions that link to static libraries that were built with MSVC 14.0, linking fails, e.g. when building Pillow:

'jpeg.lib' was created with an older compiler than other objects; rebuild old objects and libraries

It looks like practically v141 is not binary compatible with v140.

----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Fri Oct  6 19:07:09 2017
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Oct 2017 23:07:09 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1507331229.9.0.213398074469.issue31340@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Build artifacts (static libraries, in this case) are not compatible, but the built binaries are.

This may be a reasonable argument for not updating distutils's support in minor versions (and I'm totally happy to just stop updating distutils period - see the recent distutils-sig discussion for more context). If it had been raised before 3.6.3 was released then I'd have switched it back (or at least swapped the order, so if v140 was found then it would use that first and fall back on v141). Now it's done, I'm not sure whether it hurts more to change it again in 3.6.4 or not...

The immediate workaround is to set DISTUTILS_USE_SDK and run in a VS 2015 command prompt, which will bypass all the search logic. Better to rebuild the static libraries with v141 as well, but I know that's not trivial or always feasible. Alternatively, build with Python 3.6.2 or earlier - until we get the ABI stability properly figured out, that's still the best way to ensure compatibility with older releases.

I'll give the change back some more thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Fri Oct  6 20:01:07 2017
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 07 Oct 2017 00:01:07 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1507334467.27.0.213398074469.issue31340@psf.upfronthosting.co.za>


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

I build most of my binaries after calling the correct vcvarsall.bat so I did not notice until today, when I was trying to build outside that environment. 

Also, I misread your comment (https://bugs.python.org/issue31340#msg301538) earlier and did not worry at that time.

I guess this might become a bigger issue once Appveyor switches to Python 3.6.3. Projects using Anaconda's prebuilt static libraries for v140 will fail to link.

How about giving priority to VS 2015, i.e. "If you have VS 2015 then it will use that"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Fri Oct  6 20:41:15 2017
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Oct 2017 00:41:15 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507336875.67.0.213398074469.issue31712@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Presumuing your file descriptor 3 is the read end of the pipe to the child?s output, then there is probably a process somewhere that could still write to the write end. Normally ?check_output? waits until it has read all possible output from the pipe(s).

This is probably not a bug in Python. Maybe it is a bug with SSH or your ?MUX? (you didn?t explain what that is) leaving a process running in the background that could output to stderr. Try to track down what processes have your pipe open. Find out the number that identifies the pipe. It is the node number in the ?lsof? command, or in the symbolic link under /proc:

$ lsof -a -c python -d 3
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
python3 26025 vadmium    3r  FIFO    0,8      0t0 4913217 pipe
$ ls -l "/proc/$(pgrep python)/fd/3"
lr-x------ 1 vadmium vadmium 64 Oct  6 22:17 /proc/26025/fd/3 -> pipe:[4913217]

Then look through the other files to find if other process(es) have the write end of the pipe open; ?cat? in my example:

$ lsof | grep 4913217
python3   26025       vadmium    3r     FIFO        0,8      0t0    4913217 pipe
cat       26026       vadmium    1w     FIFO        0,8      0t0    4913217 pipe
$ ls -l /proc/*/fd/* | grep 4913217
lr-x------ 1 vadmium vadmium 64 Oct  6 22:17 /proc/26025/fd/3 -> pipe:[4913217]
l-wx------ 1 vadmium vadmium 64 Oct  6 22:16 /proc/26026/fd/1 -> pipe:[4913217]

The general problem does seem to be a recurring thing with the subprocess module, so maybe more documentation or other enhancements could help. Similar reports:

* Issue 31447: communicate not respecting timeout due to grandchild process
* Issue 30154: subprocess.run with timeout and output pipe from grandchild
* Issue 26534: check_output with shell=True and timeout doesn?t kill shell?s child
* Issue 23213: communicate hang with stderr leaked in ?systemd? daemon
* Issue 13422: communicate hangs as long as a daemon leaves pipes open
* Issue 4216: communicate hang after starting ?cpboot? service

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Fri Oct  6 23:50:11 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Oct 2017 03:50:11 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507348211.77.0.213398074469.issue31712@psf.upfronthosting.co.za>


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

Please try to reproduce this with Python 3.6.

On 2.7, I highly recommend you stop using the Python 2.7 subprocess module and install the subprocess32 backport available on PyPI. It is *much* more reliable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Sat Oct  7 01:00:07 2017
From: report at bugs.python.org (Steve Dower)
Date: Sat, 07 Oct 2017 05:00:07 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1507352407.47.0.213398074469.issue31340@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> How about giving priority to VS 2015

That would be the fix, but it's not worth releasing an immediate 3.6.4 IMHO and by the time 3.6.4 comes about it could be more pain to change back than to leave it. That's the balance I'm thinking about for a while.

Including Ned so he's aware. If we do a snap 3.6.4 for some other reason then it's worth swapping the order, but after a few months out there I think the damage, small as it is, will have been dealt with.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Sat Oct  7 01:03:14 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Oct 2017 05:03:14 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1507352594.74.0.213398074469.issue31340@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

If you think we should do a 3.6.4 to address this, we can do that.  I'll leave it up to your judgement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Sat Oct  7 01:27:41 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 07 Oct 2017 05:27:41 +0000
Subject: [issue31507] email.utils.parseaddr has no docstring
In-Reply-To: <1505728355.43.0.989545803706.issue31507@psf.upfronthosting.co.za>
Message-ID: <1507354061.6.0.213398074469.issue31507@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 93c0885dc84381cbbb970402b1a21bf690ee312c by Mariatta (Rohit Balasubramanian) in branch '3.6':
bpo-31507 Add docstring to parseaddr function in email.utils.parseaddr (GH-3647) (GH-3733)
https://github.com/python/cpython/commit/93c0885dc84381cbbb970402b1a21bf690ee312c


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31507>
_______________________________________

From report at bugs.python.org  Sat Oct  7 01:31:55 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 07 Oct 2017 05:31:55 +0000
Subject: [issue31507] email.utils.parseaddr has no docstring
In-Reply-To: <1505728355.43.0.989545803706.issue31507@psf.upfronthosting.co.za>
Message-ID: <1507354315.51.0.213398074469.issue31507@psf.upfronthosting.co.za>


Change by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31507>
_______________________________________

From report at bugs.python.org  Sat Oct  7 04:31:09 2017
From: report at bugs.python.org (l4mer)
Date: Sat, 07 Oct 2017 08:31:09 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507365069.45.0.213398074469.issue31712@psf.upfronthosting.co.za>


l4mer <janusz.dziedzic at gmail.com> added the comment:

janusz at nc6120:~$ ssh -V
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
janusz at nc6120:~$

I) manual check

janusz at nc6120:~$ ssh root at localhost -p 50494 -O exit
janusz at nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> cmd = ["ssh", "root at localhost", "-p", "50494"]
>>> buf = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
Terminated

janusz at nc6120:~$ ssh root at localhost -p 50494 -O exit
Exit request sent.
janusz at nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd= ["ssh", "root at localhost", "-p", "50494"]
>>> buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
Terminated

II) strace 

Correct case (mux exist):
pipe2([3, 4], O_CLOEXEC)                = 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl64(3, F_GETFL)                     = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb747a768) = 2207
close(6)                                = 0
close(4)                                = 0
brk(0x9741000)                          = 0x9741000
read(5, "", 50000)                      = 0
brk(0x9735000)                          = 0x9735000
close(5)                                = 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
_llseek(3, 0, 0xbfc1d350, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)                    = 5
read(3, "", 1)                          = 0
close(3)                                = 0
waitpid(2207, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 2207
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2207, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x8183c10, [], 0}, 8) = 0
brk(0x9733000)                          = 0x9733000
exit_group(0)                           = ?
+++ exited with 0 +++

Fail case:
read(7, "menting schedulers (this is what"..., 8192) = 8192
read(7, "\0\0\0_lent\1\0\0\0ht\10\0\0\0h_appendt\5\0\0\0i"..., 4096) = 2240
read(7, "", 4096)                       = 0
close(7)                                = 0
mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb70c7000
close(6)                                = 0
close(5)                                = 0
close(4)                                = 0
ugetrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
close(3)                                = 0
pipe2([3, 4], O_CLOEXEC)                = 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl64(3, F_GETFL)                     = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7539768) = 2238
close(6)                                = 0
close(4)                                = 0
brk(0xa30e000)                          = 0xa30e000
read(5, "", 50000)                      = 0
brk(0xa302000)                          = 0xa302000
close(5)                                = 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
_llseek(3, 0, 0xbf8a0600, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)                    = 5
read(3, 0xb710db19, 1)                  = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2238, si_uid=1000, si_status=0, si_utime=4, si_stime=1} ---
read(3,
d(3, ^Cstrace: Process 2237 detached
 <detached ...>
janusz at nc6120:~$ Traceback (most recent call last):
  File "test.py", line 6, in <module>
    buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 628, in check_output
    output, unused_err = process.communicate(timeout=timeout)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 915, in communicate
    stdout = _eintr_retry_call(self.stdout.read)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 543, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt

When hang:
janusz at nc6120:~$ ls -l "/proc/$(pgrep python)/fd/3"
lr-x------ 1 janusz janusz 64 pa?  7 10:25 /proc/2336/fd/3 -> pipe:[29858]
janusz at nc6120:~$ lsof |grep 29858
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/108/gvfs
      Output information may be incomplete.
python    2336                janusz    3r     FIFO       0,10      0t0      29858 pipe
ssh       2342                janusz    2w     FIFO       0,10      0t0      29858 pipe
janusz at nc6120:~$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Sat Oct  7 04:41:11 2017
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sat, 07 Oct 2017 08:41:11 +0000
Subject: [issue1104] msilib.SummaryInfo.GetProperty() truncates the string by
 one character
In-Reply-To: <1188943421.22.0.776458935296.issue1104@psf.upfronthosting.co.za>
Message-ID: <1507365671.42.0.213398074469.issue1104@psf.upfronthosting.co.za>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
nosy: +uranusjr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1104>
_______________________________________

From report at bugs.python.org  Sat Oct  7 04:50:15 2017
From: report at bugs.python.org (l4mer)
Date: Sat, 07 Oct 2017 08:50:15 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507366215.61.0.213398074469.issue31712@psf.upfronthosting.co.za>


l4mer <janusz.dziedzic at gmail.com> added the comment:

I) Manual test for subprocess32:

janusz at nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd = ["ssh", "root at localhost", "-p", "50494", "whoami"]
>>> buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
>>> print buf
root

>>>
janusz at nc6120:~$ ssh root at localhost -p 50494 -O exit
Exit request sent.
janusz at nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd = ["ssh", "root at localhost", "-p", "50494", "whoami"]
>>> buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
after 20 seconds
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 628, in check_output
    output, unused_err = process.communicate(timeout=timeout)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 915, in communicate
    stdout = _eintr_retry_call(self.stdout.read)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 543, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
>>>

II) When omit stderr:

janusz at nc6120:~$ ssh root at localhost -p 50494 -O exit
Exit request sent.
janusz at nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd = ["ssh", "root at localhost", "-p", "50494", "whoami"]
>>> buf = subprocess32.check_output(cmd)
>>> print buf
root

>>>

Strace for stderr=None:

mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7071000
close(6)                                = 0
close(5)                                = 0
close(4)                                = 0
ugetrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
close(3)                                = 0
pipe2([3, 4], O_CLOEXEC)                = 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl64(3, F_GETFL)                     = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb74e3768) = 2728
close(6)                                = 0
close(4)                                = 0
brk(0x93d2000)                          = 0x93d2000
read(5, "", 50000)                      = 0
brk(0x93c6000)                          = 0x93c6000
close(5)                                = 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
_llseek(3, 0, 0xbfe23f90, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)                    = 5
read(3, "", 1)                          = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2728, si_uid=1000, si_status=0, si_utime=6, si_stime=0} ---
close(3)                                = 0
waitpid(2728, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 2728
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x8183c10, [], 0}, 8) = 0
brk(0x93c4000)                          = 0x93c4000
exit_group(0)                           = ?
+++ exited with 0 +++

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Sat Oct  7 04:57:57 2017
From: report at bugs.python.org (l4mer)
Date: Sat, 07 Oct 2017 08:57:57 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507366677.84.0.213398074469.issue31712@psf.upfronthosting.co.za>


l4mer <janusz.dziedzic at gmail.com> added the comment:

Interesting when using faster machine with newer ssh don't see this problem :)

janusz at t560:~$ ssh -V
OpenSSH_7.3p1 Ubuntu-1ubuntu0.1, OpenSSL 1.0.2g  1 Mar 2016

janusz at t560:~$ ssh root at localhost -O exit; strace python test.py

getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
close(3)                                = 0
pipe2([3, 4], O_CLOEXEC)                = 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl(3, F_GETFL)                       = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)                = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb7ba6fc9d0) = 22284
close(6)                                = 0
close(4)                                = 0
brk(0xca73792000)                       = 0xca73792000
read(5, "", 50000)                      = 0
brk(0xca73786000)                       = 0xca73786000
close(5)                                = 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)                    = 5
read(3, "", 1)                          = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22284, si_uid=1000, si_status=0, si_utime=1, si_stime=0} ---
close(3)                                = 0
wait4(22284, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 22284
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fb7ba2f1630}, {0xca720ef1a0, [], SA_RESTORER, 0x7fb7ba2f1630}, 8) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

So, two options here:
- new version of ssh
- faster CPU

Will try to update ssh on the old/slow machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Sat Oct  7 05:10:48 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 Oct 2017 09:10:48 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1507367448.45.0.213398074469.issue31718@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3886
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Sat Oct  7 05:39:11 2017
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Oct 2017 09:39:11 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507369151.57.0.213398074469.issue31712@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Scanning over the Open SSH commits for 7.3p1

https://github.com/openssh/openssh-portable/compare/V_7_2_P2...V_7_3_P1

it looks like this commit

https://github.com/openssh/openssh-portable/commit/d2d6bf864e52af8491a60dd507f85b74361f5da3

may fix your problem. It points to

https://bugzilla.mindrot.org/show_bug.cgi?id=1988

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Sat Oct  7 06:16:13 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 Oct 2017 10:16:13 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1507371373.83.0.213398074469.issue31718@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

With regard to refleaks in __init__() methods, i started looking for similar refleaks
in the codebase, and hope to open an issue to fix them soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Sat Oct  7 06:28:27 2017
From: report at bugs.python.org (l4mer)
Date: Sat, 07 Oct 2017 10:28:27 +0000
Subject: [issue31712] subprocess with stderr=subprocess.STDOUT hang
In-Reply-To: <1507289950.65.0.213398074469.issue31712@psf.upfronthosting.co.za>
Message-ID: <1507372107.88.0.213398074469.issue31712@psf.upfronthosting.co.za>


l4mer <janusz.dziedzic at gmail.com> added the comment:

confirm, OpenSSH_7.3p1 solve the problem.
Thanks for help.

----------
resolution:  -> third party
status:  -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31712>
_______________________________________

From report at bugs.python.org  Sat Oct  7 09:39:30 2017
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sat, 07 Oct 2017 13:39:30 +0000
Subject: [issue31720] msilib.MSIError is spelled MsiError in documentation
Message-ID: <1507383570.37.0.213398074469.issue31720@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

The title describes it all.

----------
assignee: docs at python
components: Documentation
messages: 303877
nosy: docs at python, uranusjr
priority: normal
severity: normal
status: open
title: msilib.MSIError is spelled MsiError in documentation
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31720>
_______________________________________

From report at bugs.python.org  Sat Oct  7 09:40:20 2017
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sat, 07 Oct 2017 13:40:20 +0000
Subject: [issue31720] msilib.MSIError is spelled MsiError in documentation
In-Reply-To: <1507383570.37.0.213398074469.issue31720@psf.upfronthosting.co.za>
Message-ID: <1507383620.56.0.213398074469.issue31720@psf.upfronthosting.co.za>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
keywords: +patch
pull_requests: +3887
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31720>
_______________________________________

From report at bugs.python.org  Sat Oct  7 10:19:24 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 Oct 2017 14:19:24 +0000
Subject: [issue31721] assertion failure in FutureObj_finalize() after setting
 _log_traceback to True
Message-ID: <1507385964.19.0.213398074469.issue31721@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes an assertion failure in FutureObj_finalize() (in
Modules/_asynciomodule.c):

import asyncio
asyncio.Future()._log_traceback = True


Maybe we should allow Python code to only set it to False, and raise a
ValueError in case Python code tries to set it to True?

(PR 2050 made _log_traceback writable. Are there any usecases for setting it to
True from Python code?)

----------
components: asyncio
messages: 303878
nosy: Oren Milman, yselivanov
priority: normal
severity: normal
status: open
title: assertion failure in FutureObj_finalize() after setting _log_traceback to True
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31721>
_______________________________________

From report at bugs.python.org  Sat Oct  7 10:26:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 14:26:41 +0000
Subject: [issue31722] _io.IncrementalNewlineDecoder doesn't inherit
 codecs.IncrementalDecoder
Message-ID: <1507386401.5.0.213398074469.issue31722@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

It is documented that io.IncrementalNewlineDecoder inherits codecs.IncrementalDecoder. And the Python implementation does. But the C implementation doesn't.

>>> issubclass(_pyio.IncrementalNewlineDecoder, codecs.IncrementalDecoder)
True
>>> issubclass(_io.IncrementalNewlineDecoder, codecs.IncrementalDecoder)
False
>>> issubclass(io.IncrementalNewlineDecoder, codecs.IncrementalDecoder)
False

----------
components: IO, Library (Lib)
messages: 303879
nosy: benjamin.peterson, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: _io.IncrementalNewlineDecoder doesn't inherit codecs.IncrementalDecoder
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31722>
_______________________________________

From report at bugs.python.org  Sat Oct  7 10:28:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 14:28:38 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1507386518.34.0.213398074469.issue31718@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +benjamin.peterson, stutzbach
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Sat Oct  7 10:43:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 14:43:08 +0000
Subject: [issue31722] _io.IncrementalNewlineDecoder doesn't inherit
 codecs.IncrementalDecoder
In-Reply-To: <1507386401.5.0.213398074469.issue31722@psf.upfronthosting.co.za>
Message-ID: <1507387388.39.0.213398074469.issue31722@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

As a consequence, _io.IncrementalNewlineDecoder doesn't have the error attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31722>
_______________________________________

From report at bugs.python.org  Sat Oct  7 10:50:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 14:50:31 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507387831.82.0.213398074469.issue31165@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3888

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:00:21 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Oct 2017 15:00:21 +0000
Subject: [issue31720] msilib.MSIError is spelled MsiError in documentation
In-Reply-To: <1507383570.37.0.213398074469.issue31720@psf.upfronthosting.co.za>
Message-ID: <1507388421.33.0.213398074469.issue31720@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3889

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31720>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:02:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 15:02:03 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507388523.0.0.213398074469.issue31165@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See a4dd011259fa6f3079bd0efd95b3a136c0e3c190. The commit message:

    Tentative fix for a problem that Tim discovered at the last moment,
    and reported to python-dev: because we were calling dict_resize() in
    PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(),
    and because PyTuple_New() can cause GC, and because dict_items() calls
    PyTuple_New(), it was possible for dict_items() to have the dict
    resized right under its nose.
    
    The solution is convoluted, and touches several places: keys(),
    values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem().
    
    There are two parts to it. First, we no longer call dict_resize() in
    PyDict_Next(), which seems to solve the immediate problem.  But then
    PyDict_SetItem() must have a different policy about when *it* calls
    dict_resize(), because we want to guarantee (e.g. for an algorithm
    that Jeremy uses in the compiler) that you can loop over a dict using
    PyDict_Next() and make changes to the dict as long as those changes
    are only value replacements for existing keys using PyDict_SetItem().
    This is done by resizing *after* the insertion instead of before, and
    by remembering the size before we insert the item, and if the size is
    still the same, we don't bother to even check if we might need to
    resize.  An additional detail is that if the dict starts out empty, we
    must still resize it before the insertion.
    
    That was the first part. :-)
    
    The second part is to make keys(), values(), items(), and popitem()
    safe against side effects on the dict caused by allocations, under the
    assumption that if the GC can cause arbitrary Python code to run, it
    can cause other threads to run, and it's not inconceivable that our
    dict could be resized -- it would be insane to write code that relies
    on this, but not all code is sane.
    
    Now, I have this nagging feeling that the loops in lookdict probably
    are blissfully assuming that doing a simple key comparison does not
    change the dict's size.  This is not necessarily true (the keys could
    be class instances after all).  But that's a battle for another day.

We have the same issue with lists. PR 3915 tries to fix it by applying the same solution -- calling PyList_New() again if the source container was resized. list_slice() no longer can be considered safe, because it uses the size calculated before calling PyList_New(). Added _PyList_Copy() for copying the list for replacing unsafe PyList_GetSlice(). PyList_SetSlice() is not safe too (the PR still not fixes this). The code that uses the combination of PyList_GetSlice() and PyList_SetSlice() for safety (like in _asynciomodule.c) is not safe. Many code, including most implementations of slicing, should be rewritten if we go this way. PR 3915 shows only small example of such changes.

I think than changing the Garbage Collector would be easier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:03:48 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Oct 2017 15:03:48 +0000
Subject: [issue31720] msilib.MSIError is spelled MsiError in documentation
In-Reply-To: <1507383570.37.0.213398074469.issue31720@psf.upfronthosting.co.za>
Message-ID: <1507388628.46.0.213398074469.issue31720@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3890

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31720>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:26:32 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Oct 2017 15:26:32 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507389992.17.0.213398074469.issue31165@psf.upfronthosting.co.za>


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

> I think than changing the Garbage Collector would be easier.

What does "changing" mean exactly?  What will be the effects on normal code?  How do you know that it will not create new problems that didn't exist before?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:27:27 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 Oct 2017 15:27:27 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
Message-ID: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes refleaks:
import zipimport
zi = zipimport.zipimporter.__new__(zipimport.zipimporter)
zi.__init__('bar.zip')
zi.__init__('bar.zip')
zi.__init__('bar.zip\\foo')

This is because zipimport_zipimporter___init___impl() (in Modules/zipimport.c)
doesn't decref (if needed) before assigning to `self->files`, `self->archive`
and `self->prefix`.

I would open a PR to fix this soon.

Should i add a test to test_zipimport?
If yes, could you point out some similar refcount test to help me write this
test?

----------
components: Extension Modules
messages: 303883
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: refleaks in zipimport when calling zipimporter.__init__() more than once
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:43:52 2017
From: report at bugs.python.org (Steve Dower)
Date: Sat, 07 Oct 2017 15:43:52 +0000
Subject: [issue31340] Use VS 2017 compiler for build
In-Reply-To: <1504556235.05.0.440451459045.issue31340@psf.upfronthosting.co.za>
Message-ID: <1507391032.98.0.213398074469.issue31340@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

No, but if we need to do 3.6.4 quickly for another reason, let me know and I'll make this change.

It only affects people who are trying to share intermediate build files (which for MSVC purposes, includes static libraries) between their 3.6.2 and 3.6.3 builds. Full builds are going to be fine, and incremental builds should detect the changed tools and be able to rebuild everything. 

So it's solely cases where people are trying to manage the build around distutils rather than letting distutils handle it all that are problematic (and hey, both of these are terrible options! This is why we're discussing how to get people to just stop depending on distutils). I don't think it's worth churning the entire ecosystem just for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31340>
_______________________________________

From report at bugs.python.org  Sat Oct  7 11:45:09 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Oct 2017 15:45:09 +0000
Subject: [issue31695] Improve bigmem tests
In-Reply-To: <1507144939.6.0.213398074469.issue31695@psf.upfronthosting.co.za>
Message-ID: <1507391109.64.0.213398074469.issue31695@psf.upfronthosting.co.za>


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

+1 to all this :-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31695>
_______________________________________

From report at bugs.python.org  Sat Oct  7 12:00:29 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 07 Oct 2017 16:00:29 +0000
Subject: [issue31720] msilib.MSIError is spelled MsiError in documentation
In-Reply-To: <1507383570.37.0.213398074469.issue31720@psf.upfronthosting.co.za>
Message-ID: <1507392029.87.0.213398074469.issue31720@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 5f396dba1d11356ab18e3bec130596197e741a64 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-31720: msilib documentation, change MsiError into MSIError (GH-3914) (GH-3917)
https://github.com/python/cpython/commit/5f396dba1d11356ab18e3bec130596197e741a64


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31720>
_______________________________________

From report at bugs.python.org  Sat Oct  7 12:01:25 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 07 Oct 2017 16:01:25 +0000
Subject: [issue31720] msilib.MSIError is spelled MsiError in documentation
In-Reply-To: <1507383570.37.0.213398074469.issue31720@psf.upfronthosting.co.za>
Message-ID: <1507392085.62.0.213398074469.issue31720@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31720>
_______________________________________

From report at bugs.python.org  Sat Oct  7 12:22:10 2017
From: report at bugs.python.org (Steve Dower)
Date: Sat, 07 Oct 2017 16:22:10 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507393330.42.0.213398074469.issue31701@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Haven't had a chance to test this, but I suspect our change should depend on what happens when a C++ exception is actually unhandled.

In this case, the following sequence has occurred:
* exception is raised
* debug event is raised (if a debugger is attached)
* stack-based handlers get first-chance to ignore the exception
 * there is a stack-based handler that says "let it be raised" and the search stops
* vector-based handlers are called
* stack unwind begins, and when the handler is reached it allows execution to continue

Unfortunately, I don't think there's going to be any difference between the unhandled and handled cases at the point where our handler exists - at worst, the OS is going to say that it is "handled" and its handler will kill the process. The first chance lookup is actually there to continue execution and ignore the exception (possibly after fixing an argument or allocating a new page, etc.).

So I think our choices are:
* report no C++/CLR exceptions via faulthandler
* report all C++/CLR exceptions via faulthandler (current behaviour)

I'm inclined towards changing to the first option. The runtime is going to dump a more useful message than us if the exception makes it that far, and a C++ exception can never be caused by CPython itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Sat Oct  7 12:27:40 2017
From: report at bugs.python.org (Steve Dower)
Date: Sat, 07 Oct 2017 16:27:40 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507393660.36.0.213398074469.issue31701@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Okay, just tested taking out the C++ handler and it goes straight to an error report. Not ideal, especially since the error is logged against "python.exe" and "ucrtbase.dll" (which is going to make my life harder when reviewing the submitted crash reports), but since it can only be caused by user code, it's probably better than spamming on every handled exception.

E06D7363 (msc) and E0434352 (CCR) at least should be ignored. I think there's a third, but don't remember what it is right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Sat Oct  7 12:28:04 2017
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 07 Oct 2017 16:28:04 +0000
Subject: [issue25862] TextIOWrapper assertion failure after read() and SEEK_CUR
In-Reply-To: <1450143790.74.0.198268951027.issue25862@psf.upfronthosting.co.za>
Message-ID: <1507393684.43.0.213398074469.issue25862@psf.upfronthosting.co.za>


Change by Zackery Spytz <Osmunda46 at gmail.com>:


----------
keywords: +patch
pull_requests: +3891
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25862>
_______________________________________

From report at bugs.python.org  Sat Oct  7 12:35:00 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 Oct 2017 16:35:00 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
In-Reply-To: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>
Message-ID: <1507394100.17.0.213398074469.issue31723@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3892
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Sat Oct  7 14:18:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 18:18:17 +0000
Subject: [issue31165] list_slice() does crash if the list is mutated
 indirectly by PyList_New()
In-Reply-To: <1502329382.83.0.596499846373.issue31165@psf.upfronthosting.co.za>
Message-ID: <1507400297.89.0.213398074469.issue31165@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> What does "changing" mean exactly?

I'm not a GC expert. Maybe we should add a global flag that disable calling nontrivial destructors and set it in PyObject_GC_New(). The objects with nontrivial destructor should be added to the special queue and destroyed in "safe" place. There may be a problem with determining the "safe" place. I think that any Py_DECREF() is a "safe" place, and the eval loop is a "safe" place.

> What will be the effects on normal code?

I think this shouldn't affect Python code if perform deferred destroying in the eval loop. This can affect the execution of extensions if reference loops are created in C code. Some objects in loops can live longer that before.

> How do you know that it will not create new problems that didn't exist before?

I don't know. But we can try and see what is the result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31165>
_______________________________________

From report at bugs.python.org  Sat Oct  7 15:59:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 19:59:39 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507406379.88.0.213398074469.issue31655@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 79ba471488b936abda5ba5234b1ea90cbc94cae6 by Serhiy Storchaka in branch 'master':
bpo-31655: Validate keyword names in SimpleNamespace constructor. (#3909)
https://github.com/python/cpython/commit/79ba471488b936abda5ba5234b1ea90cbc94cae6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sat Oct  7 16:00:48 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Oct 2017 20:00:48 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507406448.29.0.213398074469.issue31655@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3893

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sat Oct  7 16:53:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 20:53:00 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507409580.3.0.213398074469.issue31655@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cae6e4775b37c412609d3a0d303c0831ff0012ff by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31655: Validate keyword names in SimpleNamespace constructor. (GH-3909) (#3920)
https://github.com/python/cpython/commit/cae6e4775b37c412609d3a0d303c0831ff0012ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sat Oct  7 16:54:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Oct 2017 20:54:37 +0000
Subject: [issue31655] SimpleNamespace accepts non-string keyword names
In-Reply-To: <1506839802.01.0.213398074469.issue31655@psf.upfronthosting.co.za>
Message-ID: <1507409677.23.0.213398074469.issue31655@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31655>
_______________________________________

From report at bugs.python.org  Sat Oct  7 22:04:38 2017
From: report at bugs.python.org (Thomas Keppler)
Date: Sun, 08 Oct 2017 02:04:38 +0000
Subject: [issue31267] threading.Timer object is affected by changes to system
 time: Python locks should use a monotonic clock if available
In-Reply-To: <1503521255.96.0.0977006158294.issue31267@psf.upfronthosting.co.za>
Message-ID: <1507428278.64.0.213398074469.issue31267@psf.upfronthosting.co.za>


Thomas Keppler <winfr34k at gmail.com> added the comment:

Hello Victor,

thank you for your update on this issue.

By looking through the other bug reports you listed, it looks as if measures were implemented but never merged. Am I right with this observation? If so, will we ever see a switch over to monotonic time?

Thanks for the info :)

--
Best regards
Thomas

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31267>
_______________________________________

From report at bugs.python.org  Sun Oct  8 01:44:01 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 05:44:01 +0000
Subject: [issue31724] test_xmlrpc should use something other than
 buildbot.python.org
Message-ID: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

With the upgrade to buildbot 0.9, the xmlrpc interface to buildbot.python.org is removed, causing test_xmlrpc to fail.  The test should hit a different host, possibly on pythontest.net?

----------
components: Tests
messages: 303894
nosy: loewis, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_xmlrpc should use something other than buildbot.python.org
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 01:50:12 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 05:50:12 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507441812.44.0.213398074469.issue31724@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
title: test_xmlrpc should use something other than buildbot.python.org -> test_xmlrpc_net should use something other than buildbot.python.org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 01:55:44 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 05:55:44 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507442144.33.0.213398074469.issue31724@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +patch
pull_requests: +3894
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 01:57:02 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 05:57:02 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507442222.92.0.213398074469.issue31724@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 02:31:26 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 06:31:26 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507444286.94.0.213398074469.issue31724@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset 73ffd3f2036179ed54591ef0455e5ba5694ae5bd by Zachary Ware in branch 'master':
bpo-31724: Skip test_xmlrpc_net (GH-3921)
https://github.com/python/cpython/commit/73ffd3f2036179ed54591ef0455e5ba5694ae5bd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 02:32:35 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Oct 2017 06:32:35 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507444355.14.0.213398074469.issue31724@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3895
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 02:40:44 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 06:40:44 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507444844.76.0.213398074469.issue31724@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This is currently mitigated by some nasty hacks on the buildbot.python.org server to avoid breaking tests on every released version of Python 3, but this still needs to change.  The test is skipped in master and (soon) 3.6 to minimize the damage when the hacks on buildbot.p.o break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 02:52:09 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Oct 2017 06:52:09 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507445529.96.0.213398074469.issue31724@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:


New changeset d13a4e50679c0861971cfae2bb226f35b8bf5142 by Zachary Ware (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31724: Skip test_xmlrpc_net (GH-3922)
https://github.com/python/cpython/commit/d13a4e50679c0861971cfae2bb226f35b8bf5142


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Sun Oct  8 03:16:44 2017
From: report at bugs.python.org (Rick J. Pelleg)
Date: Sun, 08 Oct 2017 07:16:44 +0000
Subject: [issue31725] Turtle/tkinter: NameError crashes ipython with
 "Tcl_AsyncDelete: async handler deleted by the wrong thread"
Message-ID: <1507447004.91.0.213398074469.issue31725@psf.upfronthosting.co.za>


New submission from Rick J. Pelleg <rickjpelleg at gmail.com>:

On Windows 10 Education, ran:
ipython
Python 3.6.3 (v3.6.3:2c5fed8, Oct  3 2017, 17:26:49) [MSC v.1900 32 bit (Intel)]
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.
----
After "from turtle import *" and several simple turtle commands:

In [36]: fill()
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-36-4268fc8160e4> in <module>()
----> 1 fill()

NameError: name 'fill' is not defined

Tcl_AsyncDelete: async handler deleted by the wrong thread
Exception ignored in: <bound method Image.__del__ of <tkinter.PhotoImage object at 0x0465AEB0>>
Traceback (most recent call last):
  File "d:\users\yuval\appdata\local\programs\python\python36-32\lib\tkinter\__init__.py", line 3501, in __del__
    self.tk.call('image', 'delete', self.name)

----------
components: Tkinter
messages: 303898
nosy: Rick J. Pelleg
priority: normal
severity: normal
status: open
title: Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31725>
_______________________________________

From report at bugs.python.org  Sun Oct  8 03:30:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 07:30:51 +0000
Subject: [issue31271] an assertion failure in io.TextIOWrapper.write
In-Reply-To: <1503597989.21.0.785820469546.issue31271@psf.upfronthosting.co.za>
Message-ID: <1507447851.73.0.213398074469.issue31271@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You are right. But in any case the test should be fixed for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31271>
_______________________________________

From report at bugs.python.org  Sun Oct  8 03:44:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 07:44:13 +0000
Subject: [issue31642] None value in sys.modules no longer blocks import
In-Reply-To: <1506716472.27.0.213398074469.issue31642@psf.upfronthosting.co.za>
Message-ID: <1507448652.99.0.213398074469.issue31642@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f07e2b64df6304a36fb5e29397d3c77a7ba17704 by Serhiy Storchaka in branch 'master':
bpo-31642: Restore blocking "from" import by setting None in sys.modules. (#3834)
https://github.com/python/cpython/commit/f07e2b64df6304a36fb5e29397d3c77a7ba17704


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31642>
_______________________________________

From report at bugs.python.org  Sun Oct  8 04:08:56 2017
From: report at bugs.python.org (Franck Pommereau)
Date: Sun, 08 Oct 2017 08:08:56 +0000
Subject: [issue31726] Missing token.COMMENT
Message-ID: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>


New submission from Franck Pommereau <franck.pommereau at gmail.com>:

Module token does not have constant COMMENT. But tokenize produces it and it appears in tok_name.

----------
components: Library (Lib)
messages: 303901
nosy: fpom
priority: normal
severity: normal
status: open
title: Missing token.COMMENT
type: enhancement
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 04:15:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 08:15:31 +0000
Subject: [issue31642] None value in sys.modules no longer blocks import
In-Reply-To: <1506716472.27.0.213398074469.issue31642@psf.upfronthosting.co.za>
Message-ID: <1507450531.76.0.213398074469.issue31642@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31642>
_______________________________________

From report at bugs.python.org  Sun Oct  8 04:17:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 08:17:49 +0000
Subject: [issue28280] Always return a list from
 PyMapping_Keys/PyMapping_Values/PyMapping_Items
In-Reply-To: <1474913626.43.0.560302545775.issue28280@psf.upfronthosting.co.za>
Message-ID: <1507450669.02.0.213398074469.issue28280@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0ccc0f6c7495be9043300e22d8f38e6d65e8884f by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-28280: Make PyMapping_Keys(), PyMapping_Values() and PyMapping_Items() always return a list (#3840)
https://github.com/python/cpython/commit/0ccc0f6c7495be9043300e22d8f38e6d65e8884f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28280>
_______________________________________

From report at bugs.python.org  Sun Oct  8 05:16:22 2017
From: report at bugs.python.org (Franck Pommereau)
Date: Sun, 08 Oct 2017 09:16:22 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507454182.1.0.213398074469.issue31726@psf.upfronthosting.co.za>


Franck Pommereau <franck.pommereau at gmail.com> added the comment:

Actually, comparing with the content of tok_name, all the following constants are missing:

COMMENT = 54
NL = 55
BACKQUOTE = 56
ATEQUAL = 57

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 05:52:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 09:52:00 +0000
Subject: [issue31642] None value in sys.modules no longer blocks import
In-Reply-To: <1506716472.27.0.213398074469.issue31642@psf.upfronthosting.co.za>
Message-ID: <1507456320.69.0.213398074469.issue31642@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6f059ab80a351a7dd85cc57c5ca240f817a79c5d by Serhiy Storchaka in branch '3.6':
[3.6] bpo-31642: Restore blocking "from" import by setting None in sys.modules. (GH-3834). (#3923)
https://github.com/python/cpython/commit/6f059ab80a351a7dd85cc57c5ca240f817a79c5d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31642>
_______________________________________

From report at bugs.python.org  Sun Oct  8 05:53:36 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 09:53:36 +0000
Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx
In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za>
Message-ID: <1507456416.41.0.213398074469.issue27867@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4d3f084c035ad3dfd9f8479886c41b1b1823ace2 by Serhiy Storchaka in branch 'master':
bpo-27867: Add a porting guide for PySlice_GetIndicesEx(). (#1973)
https://github.com/python/cpython/commit/4d3f084c035ad3dfd9f8479886c41b1b1823ace2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27867>
_______________________________________

From report at bugs.python.org  Sun Oct  8 05:54:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 09:54:02 +0000
Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx
In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za>
Message-ID: <1507456442.19.0.213398074469.issue27867@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27867>
_______________________________________

From report at bugs.python.org  Sun Oct  8 05:55:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 09:55:13 +0000
Subject: [issue31642] None value in sys.modules no longer blocks import
In-Reply-To: <1506716472.27.0.213398074469.issue31642@psf.upfronthosting.co.za>
Message-ID: <1507456513.57.0.213398074469.issue31642@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31642>
_______________________________________

From report at bugs.python.org  Sun Oct  8 05:57:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 09:57:05 +0000
Subject: [issue31725] Turtle/tkinter: NameError crashes ipython with
 "Tcl_AsyncDelete: async handler deleted by the wrong thread"
In-Reply-To: <1507447004.91.0.213398074469.issue31725@psf.upfronthosting.co.za>
Message-ID: <1507456625.63.0.213398074469.issue31725@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Can you reproduce the issue without IPython?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31725>
_______________________________________

From report at bugs.python.org  Sun Oct  8 06:43:05 2017
From: report at bugs.python.org (Joel Nothman)
Date: Sun, 08 Oct 2017 10:43:05 +0000
Subject: [issue16516] argparse types (and actions) must be hashable
In-Reply-To: <1353468507.9.0.0965555550975.issue16516@psf.upfronthosting.co.za>
Message-ID: <1507459385.19.0.213398074469.issue16516@psf.upfronthosting.co.za>


Joel Nothman <joel.nothman at gmail.com> added the comment:

Clearly this is not in high demand

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16516>
_______________________________________

From report at bugs.python.org  Sun Oct  8 07:16:11 2017
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Oct 2017 11:16:11 +0000
Subject: [issue16516] argparse types (and actions) must be hashable
In-Reply-To: <1353468507.9.0.0965555550975.issue16516@psf.upfronthosting.co.za>
Message-ID: <1507461371.69.0.213398074469.issue16516@psf.upfronthosting.co.za>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16516>
_______________________________________

From report at bugs.python.org  Sun Oct  8 08:02:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 12:02:58 +0000
Subject: [issue31490] assertion failure in ctypes in case an _anonymous_ attr
 appears outside _fields_
In-Reply-To: <1505555858.95.0.114491369101.issue31490@psf.upfronthosting.co.za>
Message-ID: <1507464178.06.0.213398074469.issue31490@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In 2.7 "%U" is not recognized in the format string.

>>> class Name(Structure):
...     _fields_ = []
...     _anonymous_ = ["x"]
...     x = 42
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '%U' is specified in _anonymous_ but not in _fields_

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31490>
_______________________________________

From report at bugs.python.org  Sun Oct  8 10:54:53 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Oct 2017 14:54:53 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507474493.81.0.213398074469.issue31726@psf.upfronthosting.co.za>


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

This is fixed in python3.  Do you have a use case for 2.7 or are you just noticing?

----------
nosy: +r.david.murray
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 11:24:34 2017
From: report at bugs.python.org (Rick J. Pelleg)
Date: Sun, 08 Oct 2017 15:24:34 +0000
Subject: [issue31725] Turtle/tkinter: NameError crashes ipython with
 "Tcl_AsyncDelete: async handler deleted by the wrong thread"
In-Reply-To: <1507456625.63.0.213398074469.issue31725@psf.upfronthosting.co.za>
Message-ID: <CADB7NfPoZqq2JzNFppWebQiSBssr4fyJB=fsq_OLguhtECoidw@mail.gmail.com>


Rick J. Pelleg <rickjpelleg at gmail.com> added the comment:

Mmm... right now I cannot reproduce at all, both in iPython and in python.
Will continue to try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31725>
_______________________________________

From report at bugs.python.org  Sun Oct  8 11:46:01 2017
From: report at bugs.python.org (Franck Pommereau)
Date: Sun, 08 Oct 2017 15:46:01 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507477561.47.0.213398074469.issue31726@psf.upfronthosting.co.za>


Franck Pommereau <franck.pommereau at gmail.com> added the comment:

I have the problem still exists in 3.4.3 at least:

Python 3.4.3 (default, Nov 17 2016, 01:08:31) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import token
>>> token.COMMENT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'COMMENT'

About the use case: I often use tokenize to build recursive descendant parsers for domain-specific languages. Not having all the token constants can be worked around with code below, but it would be so better to have a complete module...  :)

import token
_tok = next(tokenize.tokenize(io.BytesIO(b"").readline))
token.tok_name[_tok.type] = "BACKQUOTE"
for number, name in token.tok_name.items() :
    if not hasattr(token, name) :
        setattr(token, name, number)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 12:18:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Oct 2017 16:18:56 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507479536.75.0.213398074469.issue31726@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

COMMENT and NL are added by the tokenize module. BACKQUOTE already is set, but to 25 instead of 56. ATEQUAL shouldn't be occurred in Python earlier than 3.5. How did you get your results?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 12:38:09 2017
From: report at bugs.python.org (Franck Pommereau)
Date: Sun, 08 Oct 2017 16:38:09 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507480689.1.0.213398074469.issue31726@psf.upfronthosting.co.za>


Franck Pommereau <franck.pommereau at gmail.com> added the comment:

I've just launched ipython3 (installed with pip):

$ ipython3
Python 3.4.3 (default, Nov 17 2016, 01:08:31) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import token, tokenize, io

In [2]: token.BACKQUOTE
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-2-ebc28b79826c> in <module>()
----> 1 token.BACKQUOTE

AttributeError: 'module' object has no attribute 'BACKQUOTE'

In [3]: _tok = next(tokenize.tokenize(io.BytesIO(b"").readline))

In [4]: token.tok_name[_tok.type] = "BACKQUOTE"

In [5]: for number, name in token.tok_name.items() :
   ...:     if not hasattr(token, name) :
   ...:         print(name, "=", number)
   ...:         
COMMENT = 54
NL = 55
BACKQUOTE = 56
ATEQUAL = 57
COMMENT = 58

If instead I use python3 as provided by my Linux Mint, the result is different indeed:

$ python3
Python 3.4.3 (default, Nov 17 2016, 01:08:31) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import token, tokenize, io
>>> token.BACKQUOTE
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'BACKQUOTE'
>>> _tok = next(tokenize.tokenize(io.BytesIO(b"").readline))
>>> token.tok_name[_tok.type] = "BACKQUOTE"
>>> for number, name in token.tok_name.items() :
...     if not hasattr(token, name) :
...         print(name, "=", number)
... 
COMMENT = 54
NL = 55
BACKQUOTE = 56

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 13:08:41 2017
From: report at bugs.python.org (Jonathan)
Date: Sun, 08 Oct 2017 17:08:41 +0000
Subject: [issue31727] FTP_TLS errors when
Message-ID: <1507482521.5.0.213398074469.issue31727@psf.upfronthosting.co.za>


New submission from Jonathan <bugreports at lightpear.com>:

Using Python 3.6.3.

The below issue only happens with FTP_TLS. It works fine via a plain FTP connection.

I am connecting to an FTP to using `ftplib` via FTP_TLS.

	ftps = ftplib.FTP_TLS('example.com', timeout=5)

	# TLS is more secure than SSL
	ftps.ssl_version = ssl.PROTOCOL_TLS

	# login before securing control channel
	ftps.login('username at example.com', 'password')

	# switch to secure data connection
	ftps.prot_p()

	# Explicitly set Passive mode
	ftps.set_pasv(True)

This all works. I can send `ftps.mkd('mydir')` (make directory) and `ftps.cwd('mydir')` (change working dir), and both work fine.

But if I send **any** of these (they're all basically synonyms as far as I can tell):

			ftps.dir()
			ftps.nlst()
			ftps.retrlines('LIST')
			ftps.retrlines('MLSD')

Then I get back an exception (below also includes all ftplib debug info as well; generally matches up with what FileZilla shows too):

	*cmd* 'AUTH TLS'
	*put* 'AUTH TLS\r\n'
	*get* '234 AUTH TLS OK.\n'
	*resp* '234 AUTH TLS OK.'
	*cmd* 'USER username at example.com'
	*put* 'USER username at example.com\r\n'
	*get* '331 User username at example.com OK. Password required\n'
	*resp* '331 User username at example.com OK. Password required'
	*cmd* 'PASS ******************************'
	*put* 'PASS ******************************\r\n'
	*get* '230 OK. Current restricted directory is /\n'
	*resp* '230 OK. Current restricted directory is /'
	*cmd* 'PBSZ 0'
	*put* 'PBSZ 0\r\n'
	*get* '200 PBSZ=0\n'
	*resp* '200 PBSZ=0'
	*cmd* 'PROT P'
	*put* 'PROT P\r\n'
	*get* '200 Data protection level set to "private"\n'
	*resp* '200 Data protection level set to "private"'
	*cmd* 'MKD mydir'
	*put* 'MKD mydir\r\n'
	*get* '257 "mydir" : The directory was successfully created\n'
	*resp* '257 "mydir" : The directory was successfully created'
	*cmd* 'CWD mydir'
	*put* 'CWD mydir\r\n'
	*get* '250 OK. Current directory is /mydir\n'
	*resp* '250 OK. Current directory is /mydir'
	*cmd* 'TYPE A'
	*put* 'TYPE A\r\n'
	*get* '200 TYPE is now ASCII\n'
	*resp* '200 TYPE is now ASCII'
	*cmd* 'PASV'
	*put* 'PASV\r\n'
	*get* '227 Entering Passive Mode (8,8,8,8,8,8)\n'
	*resp* '227 Entering Passive Mode (8,8,8,8,8,8)'
	*cmd* 'MLSD'
	*put* 'MLSD\r\n'
	*get* '150 Accepted data connection\n'
	*resp* '150 Accepted data connection'
	Traceback (most recent call last):
	  File "c:\my_script.py", line 384, in run_ftps
		ftps.retrlines('MLSD')
	  File "c:\libs\Python36\lib\ftplib.py", line 485, in retrlines
		conn.unwrap()
	  File "C:\libs\Python36\lib\ssl.py", line 1051, in unwrap
		s = self._sslobj.unwrap()
	  File "C:\libs\Python36\lib\ssl.py", line 698, in unwrap
		return self._sslobj.shutdown()
	OSError: [Errno 0] Error

The same FTP command (LIST) works fine via filezilla.

The closest thing I can find with googling is this: https://bugs.python.org/msg253161 - and I'm not sure if it's related or relevant.

Short version: What does "OSError: [Errno 0] Error" actually mean, and how do I list my directory contents?

----------
messages: 303914
nosy: jonathan-lp
priority: normal
severity: normal
status: open
title: FTP_TLS errors when
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31727>
_______________________________________

From report at bugs.python.org  Sun Oct  8 13:12:30 2017
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Oct 2017 17:12:30 +0000
Subject: [issue31727] FTP_TLS errors when
In-Reply-To: <1507482521.5.0.213398074469.issue31727@psf.upfronthosting.co.za>
Message-ID: <1507482750.5.0.213398074469.issue31727@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31727>
_______________________________________

From report at bugs.python.org  Sun Oct  8 15:48:17 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Oct 2017 19:48:17 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507492097.57.0.213398074469.issue31726@psf.upfronthosting.co.za>


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

3.4 and 3.5 are in security maintenance mode only, and this is not a security bug.  This was fixed in master (3.7) as a result of issue 25324.  The decision there was made to not backport it because no one had complained about the problem previously.  Now we have a complaint, so perhaps that decision should be revisited?

There's also Serhiy's issue 30455.  I'm not sure if he's thinking about backporting that one or not.

And then there is the 2.7 question.  I'm not sure this is strong enough motivation to fix it there, though I wouldn't object (consistency is good).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Sun Oct  8 15:55:26 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Oct 2017 19:55:26 +0000
Subject: [issue31092] delicate behaviour of shared (managed) multiprocessing
 Queues
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507492526.76.0.213398074469.issue31092@psf.upfronthosting.co.za>


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

@Prof Plum

> When I call pool.apply_async() I expect it only to return when the worker process has been started and finished it's initialization process

Well... it's called *async* for a reason, so I'm not sure why the behaviour would be partially synchronous.

@Oren

> Should we fix this?

I'm not sure how.  In mp.Pool we don't want to keep references to input objects longer than necessary.

> Or is it the responsibility of the user to not destroy shared objects too soon?  (In that case, maybe we should mention it in the docs?)

Yes to both questions, IMO.

(note: changing title to better reflect issue)

----------
title: multiprocessing.Manager() race condition -> delicate behaviour of shared (managed) multiprocessing Queues

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Sun Oct  8 16:16:27 2017
From: report at bugs.python.org (Oren Milman)
Date: Sun, 08 Oct 2017 20:16:27 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
Message-ID: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes the interpreter to crash:
import xml.etree.ElementTree
class X:
    def __del__(self):
        elem.clear()
elem = xml.etree.ElementTree.Element('elem')
elem.text = X()
elem.clear()

This is because _elementtree_Element_clear_impl() decrefs self->text in an
unsafe manner.
For the same reason, but for self->tail, a crash would happen if we replaced
'elem.text = X()' with 'elem.tail = X()'.


Similarly, the following code also causes the interpreter to crash:
import xml.etree.ElementTree
class X:
    def __del__(self):
        elem.clear()
elem = xml.etree.ElementTree.Element('elem')
elem.text = X()
elem.text = X()

This is because element_text_setter() decrefs self->text in an unsafe manner.
element_tail_setter() does the same for self->tail, so again, if we replaced
'elem.text = X()' with 'elem.tail = X()', we would also get a crash.

----------
components: XML
messages: 303917
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crashes in _elementtree due to unsafe decrefs of Element.text and Element.tail
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Sun Oct  8 16:51:11 2017
From: report at bugs.python.org (gene@nlc.co.nz)
Date: Sun, 08 Oct 2017 20:51:11 +0000
Subject: [issue31729] multiprocesssing.Pool.map_async() undocumented
Message-ID: <1507495871.16.0.213398074469.issue31729@psf.upfronthosting.co.za>


New submission from gene at nlc.co.nz <gene at nlc.co.nz>:

To monitor how much of my multiprocess.Pool is completed I am forced to use undocumented features which I fear mat changed in the future. Especially result._number_left which looks like a private variable. Can you please document the result from Pool.map_async() and make the _number_left a proper method, e.g result.number_completed()

result = pool.map_async(process_employee, gen_emps, chunksize=1)
while not result.ready():
   left = result._number_left

It is not possible to pass Pipes, Queues or Shared memory to Pool workers in order for them to signal back to the master when them have completed a job.

----------
components: Library (Lib)
messages: 303918
nosy: gene at nlc.co.nz
priority: normal
severity: normal
status: open
title: multiprocesssing.Pool.map_async() undocumented
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31729>
_______________________________________

From report at bugs.python.org  Sun Oct  8 16:54:49 2017
From: report at bugs.python.org (gene@nlc.co.nz)
Date: Sun, 08 Oct 2017 20:54:49 +0000
Subject: [issue31730] list unhashable, can not be use as key to dict
Message-ID: <1507496089.59.0.213398074469.issue31730@psf.upfronthosting.co.za>


New submission from gene at nlc.co.nz <gene at nlc.co.nz>:

A list can no be used as the key to a dict, apparently because it is "unhashable": TypeError: unhashable type: 'list'.

The code must exist to hash object like this a tuple is hashable and can be constructed from a list.

----------
components: Interpreter Core
messages: 303919
nosy: gene at nlc.co.nz
priority: normal
severity: normal
status: open
title: list unhashable, can not be use as key to dict
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31730>
_______________________________________

From report at bugs.python.org  Sun Oct  8 17:02:03 2017
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Oct 2017 21:02:03 +0000
Subject: [issue31730] list unhashable, can not be use as key to dict
In-Reply-To: <1507496089.59.0.213398074469.issue31730@psf.upfronthosting.co.za>
Message-ID: <1507496523.09.0.213398074469.issue31730@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

As documented, a dict key must be hashable and, because lists are not immutable, they are not hashable and thus can't be used as keys.  See the Python Glossary for more info.  https://docs.python.org/2/glossary.html

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31730>
_______________________________________

From report at bugs.python.org  Sun Oct  8 17:03:31 2017
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Oct 2017 21:03:31 +0000
Subject: [issue31729] multiprocesssing.Pool.map_async() undocumented
In-Reply-To: <1507495871.16.0.213398074469.issue31729@psf.upfronthosting.co.za>
Message-ID: <1507496611.93.0.213398074469.issue31729@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31729>
_______________________________________

From report at bugs.python.org  Sun Oct  8 17:09:29 2017
From: report at bugs.python.org (Oren Milman)
Date: Sun, 08 Oct 2017 21:09:29 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507496969.62.0.213398074469.issue31728@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3897
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Sun Oct  8 17:22:37 2017
From: report at bugs.python.org (Prof Plum)
Date: Sun, 08 Oct 2017 21:22:37 +0000
Subject: [issue31092] delicate behaviour of shared (managed) multiprocessing
 Queues
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507497757.38.0.213398074469.issue31092@psf.upfronthosting.co.za>


Prof Plum <dwyerfire at gmail.com> added the comment:

@Antoine Pitrou

>Well... it's called *async* for a reason, so I'm not sure why the behaviour would be partially synchronous.

To a avoid race condition

>I'm not sure how.  In mp.Pool we don't want to keep references to input objects longer than necessary.

Like I said you could just add some sort of "safe" flag to the apply_async() call safe=True would mean the initialization of the worker is done synchronously safe=False would be the normal behavior. Even if you decide it's the user's responsibility to not delete the queue if the user's code is exiting a function that would basically amount to them calling sleep() for some guessed amount of time. With a safe flag they wouldn't have to guess the time or call sleep which is kinda ugly IMO. Also if someone see's that apply_async() has a safe flag they are more likely to look up what it does than they are to read the full docs to apply_async().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Sun Oct  8 17:48:28 2017
From: report at bugs.python.org (gene@nlc.co.nz)
Date: Sun, 08 Oct 2017 21:48:28 +0000
Subject: [issue31729] multiprocesssing.pool.AsyncResult undocumented field
In-Reply-To: <1507495871.16.0.213398074469.issue31729@psf.upfronthosting.co.za>
Message-ID: <1507499308.72.0.213398074469.issue31729@psf.upfronthosting.co.za>


Change by gene at nlc.co.nz <gene at nlc.co.nz>:


----------
title: multiprocesssing.Pool.map_async() undocumented -> multiprocesssing.pool.AsyncResult undocumented field

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31729>
_______________________________________

From report at bugs.python.org  Sun Oct  8 22:54:14 2017
From: report at bugs.python.org (Bradley Smith)
Date: Mon, 09 Oct 2017 02:54:14 +0000
Subject: [issue31537] Bug in readline module documentation example
In-Reply-To: <1505938727.72.0.626220071672.issue31537@psf.upfronthosting.co.za>
Message-ID: <1507517654.54.0.213398074469.issue31537@psf.upfronthosting.co.za>


Change by Bradley Smith <brad82 at gmail.com>:


----------
keywords: +patch
pull_requests: +3898
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31537>
_______________________________________

From report at bugs.python.org  Sun Oct  8 22:56:45 2017
From: report at bugs.python.org (Bradley Smith)
Date: Mon, 09 Oct 2017 02:56:45 +0000
Subject: [issue31537] Bug in readline module documentation example
In-Reply-To: <1505938727.72.0.626220071672.issue31537@psf.upfronthosting.co.za>
Message-ID: <1507517805.6.0.213398074469.issue31537@psf.upfronthosting.co.za>


Bradley Smith <brad82 at gmail.com> added the comment:

I ran into the same bug in the documentation recently. I've opened a pull request here that fixes it:

https://github.com/python/cpython/pull/3925

As I was trying to figure out why the example was broken, I wrote up a little more context to explain the current behavior and the fix:

https://docs.python.org/3.7/library/readline.html#example
https://docs.python.org/3.6/library/readline.html#example

In the "Example" section, the second example that "supports concurrent interactive sessions, by only appending the new history" will actually *never* write any lines to a custom history file. This is conveniently masked by the fact that the file path used in the example code also happens to be the default path that readline automatically writes history to, but if you specify *any* other file path, you will see that the new file is created but never has any content written to it.

The problem in this example is the use of `get_history_length` to get "previous" and "current" history lengths for determining how many lines to append to the file. Both calls to `get_history_length` always return `-1` here. Thus, when `append_history_file` is called, it always receives a first argument of `0` (because `-1 - -1 == 0`), resulting in zero lines written to the file.

Instead of `get_history_length`, the example code *should* call `get_current_history_length`. Swapping that function call makes the example behave as expected, appending new lines to the file.

----------
nosy: +infinitewarp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31537>
_______________________________________

From report at bugs.python.org  Mon Oct  9 01:20:04 2017
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 09 Oct 2017 05:20:04 +0000
Subject: [issue31698] Add REQ_NAME to the node.h API
In-Reply-To: <1507177705.75.0.213398074469.issue31698@psf.upfronthosting.co.za>
Message-ID: <1507526404.51.0.213398074469.issue31698@psf.upfronthosting.co.za>


Change by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


----------
keywords: +patch
pull_requests: +3900
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31698>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:13:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 07:13:25 +0000
Subject: [issue31731] test_io hangs on
Message-ID: <1507533205.95.0.213398074469.issue31731@psf.upfronthosting.co.za>


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

test_io is running since longer than 5 hours on x86 Gentoo Refleaks 2.7:

http://buildbot.python.org/all/#/builders/78/builds/1/steps/4/logs/stdio

2:12:11 load avg: 3.26 [402/403] test_contains passed -- running: test_io (1739 sec)
beginning 6 repetitions
123456
......
running: test_io (1769 sec)
running: test_io (1799 sec)
(...)
running: test_io (19529 sec)

http://buildbot.python.org/all/#/builders/78/builds/1/steps/4/logs/stdio

----------
messages: 303924
nosy: haypo
priority: normal
severity: normal
status: open
title: test_io hangs on

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31731>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:14:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 07:14:58 +0000
Subject: [issue31731] [2.7] test_io hangs on x86 Gentoo Refleaks 2.7
In-Reply-To: <1507533205.95.0.213398074469.issue31731@psf.upfronthosting.co.za>
Message-ID: <1507533298.27.0.213398074469.issue31731@psf.upfronthosting.co.za>


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

I interrupted the build.

----------
components: +Tests
nosy: +zach.ware
title: test_io hangs on -> [2.7] test_io hangs on x86 Gentoo Refleaks 2.7
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31731>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:20:11 2017
From: report at bugs.python.org (Iryna Shcherbina)
Date: Mon, 09 Oct 2017 07:20:11 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507533611.24.0.213398074469.issue31719@psf.upfronthosting.co.za>


Iryna Shcherbina <shcherbina.iryna at gmail.com> added the comment:

I have run a build with the patch applied, and can confirm that the tests  pass on s390x.
Full build log can be viewed here: https://kojipkgs.fedoraproject.org//work/tasks/9473/22339473/build.log

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:37:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 07:37:26 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507534646.53.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

On the Internet, I also found the code 0xE0434F4D: 0xe0000000 + 'COM'. Should it be ignored as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:44:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 07:44:53 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507535093.26.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

> So I think our choices are:
> * report no C++/CLR exceptions via faulthandler
> * report all C++/CLR exceptions via faulthandler (current behaviour)
>
> I'm inclined towards changing to the first option. (...)

On the Internet, I found users asking why their favorite application crashed with "Unhandled Exception E0434F4D (e0434fedh) at address 7C81EB33h" or "APPCRASH Exception Code e0434f4d".

While I understand that it's annoying to get a traceback each time an application handles an exception, the faulthandler would leave the user clueless if faulthandler ignore such exception and the exception "kills" the process.

faulthandler registers its exception handler as the *first* handler to be called:

   AddVectoredExceptionHandler(1, faulthandler_exc_handler);

Maybe it shouldn't be the first but the *last* to be called? So an earlier handler could handle the exception, and faulthandler wouldn't log its traceback.

The problem is that I'm confused with "non-error" exceptions (code < 0x80000000), "expected" MSC or COM exceptions, and fatal exceptions like EXCEPTION_INT_DIVIDE_BY_ZERO or EXCEPTION_ACCESS_VIOLATION.

Is it possible to be asked to be called as the last handler, and still be able to log EXCEPTION_ACCESS_VIOLATION? If not, maybe we need two handlers depending on the exception code. One handler called last for non-fatal exceptions, one handler called first for fatal exceptions.

By "Fatal" exceptions, I mean:

    case EXCEPTION_ACCESS_VIOLATION: PUTS(fd, "access violation"); break;
    case EXCEPTION_FLT_DIVIDE_BY_ZERO: PUTS(fd, "float divide by zero"); break;
    case EXCEPTION_FLT_OVERFLOW: PUTS(fd, "float overflow"); break;
    case EXCEPTION_INT_DIVIDE_BY_ZERO: PUTS(fd, "int divide by zero"); break;
    case EXCEPTION_INT_OVERFLOW: PUTS(fd, "integer overflow"); break;
    case EXCEPTION_IN_PAGE_ERROR: PUTS(fd, "page error"); break;
    case EXCEPTION_STACK_OVERFLOW: PUTS(fd, "stack overflow"); break;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:49:48 2017
From: report at bugs.python.org (Franck Pommereau)
Date: Mon, 09 Oct 2017 07:49:48 +0000
Subject: [issue31726] Missing token.COMMENT
In-Reply-To: <1507450136.57.0.213398074469.issue31726@psf.upfronthosting.co.za>
Message-ID: <1507535388.61.0.213398074469.issue31726@psf.upfronthosting.co.za>


Franck Pommereau <franck.pommereau at gmail.com> added the comment:

Thanks for the explanation! Fixing is up to you, Python developers. But since there's a simple workaround, maybe it doesn't worth the effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31726>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:52:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 07:52:12 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507535532.64.0.213398074469.issue31719@psf.upfronthosting.co.za>


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


New changeset cc4b6f1c6210460c0645b1df508e114e16805784 by Victor Stinner in branch '2.7':
bpo-31719: Fix test_regrtest.test_crashed() on s390x (#3912)
https://github.com/python/cpython/commit/cc4b6f1c6210460c0645b1df508e114e16805784


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Mon Oct  9 03:56:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 07:56:03 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507535763.88.0.213398074469.issue31719@psf.upfronthosting.co.za>


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

For the records, test_regrtest.test_crashed() uses faulthandler._sigsegv() in the master branch. This function calls raise(SIGSEGV) directly, rather than trying to read from NULL (address 0).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Mon Oct  9 04:24:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 08:24:27 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507537467.94.0.213398074469.issue31719@psf.upfronthosting.co.za>


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

The main issue with reading from NULL is that it may not crash on AIX.  But I checked: test_regrtest passed on our AIX buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:21:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 09:21:51 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507540911.89.0.213398074469.issue31692@psf.upfronthosting.co.za>


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


----------
pull_requests: +3901

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:21:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 09:21:52 +0000
Subject: [issue19527] Test failures with COUNT_ALLOCS
In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za>
Message-ID: <1507540912.03.0.00913614298617.issue19527@psf.upfronthosting.co.za>


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


----------
pull_requests: +3902

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

From report at bugs.python.org  Mon Oct  9 05:22:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 09:22:53 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507540973.58.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

Ok, so. I wrote a different PR: PR 3927 adds a new PYTHONSHOWALLOCCOUNT environment variable and write allocations statistics into stderr (rather than stdout) when PYTHONSHOWALLOCCOUNT is set.

The PR also fixes the test suite for COUNT_ALLOCS.

The PR 3927 is much shorter because PYTHONSHOWALLOCCOUNT now has to be defined to dump allocations statistics.

haypo at selma$ git diff 2.7.. --stat
 Doc/using/cmdline.rst                                                       | 7 +++++++
 Lib/test/support/__init__.py                                                | 3 +++
 Lib/test/test_abc.py                                                        | 1 +
 Lib/test/test_gc.py                                                         | 4 +++-
 Lib/test/test_regrtest.py                                                   | 1 +
 Lib/test/test_sys.py                                                        | 5 ++++-
 Lib/test/test_weakref.py                                                    | 1 +
 Misc/NEWS.d/next/Core and Builtins/2017-10-09-11-03-13.bpo-31692.5-bpdk.rst | 4 ++++
 Python/pythonrun.c                                                          | 4 +++-
 9 files changed, 27 insertions(+), 3 deletions(-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:33:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 09:33:52 +0000
Subject: [issue31267] threading.Timer object is affected by changes to system
 time: Python locks should use a monotonic clock if available
In-Reply-To: <1503521255.96.0.0977006158294.issue31267@psf.upfronthosting.co.za>
Message-ID: <1507541632.35.0.213398074469.issue31267@psf.upfronthosting.co.za>


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

> it looks as if measures were implemented but never merged.

The blocker issue is that sem_timedwait() doesn't support CLOCK_MONOTONIC. The glibc has to be enhanced to support this new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31267>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:35:23 2017
From: report at bugs.python.org (Scott Tucholka)
Date: Mon, 09 Oct 2017 09:35:23 +0000
Subject: [issue31666] Pandas_datareader Error Message - ModuleNotFoundError:
 No module named 'pandas_datareader' with module in folder
In-Reply-To: <1507309056.54.0.213398074469.issue31666@psf.upfronthosting.co.za>
Message-ID: <CAAueH1NEG1jnu2Ke0CARfp2LxLXzGo0FsRuvLtnvECrwpwczDw@mail.gmail.com>


Scott Tucholka <s.tucholka at gmail.com> added the comment:

I am running Windows 10 Enterprise x64 and use Spyder (Python 3.6).

This is my code:
import pandas as pd
import pandas_datareader as dr
dr.get_data_yahoo('AAPL')

I am expecting that the module will import and the get_data_yahoo will
return results for 'AAPL'.

This is my log:
Python 3.6.2 |Anaconda, Inc.| (default, Sep 19 2017, 08:03:39) [MSC v.1900
64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.
IPython 6.1.0 -- An enhanced Interactive Python.
import pandas as pd
import pandas_datareader as dr
dr.get_data_yahoo('AAPL')
Traceback (most recent call last):
  File "<ipython-input-1-43a2f11394e3>", line 2, in <module>
    import pandas_datareader as dr
ModuleNotFoundError: No module named 'pandas_datareader'

Thanks

On Fri, Oct 6, 2017 at 12:57 PM, ?ric Araujo <report at bugs.python.org> wrote:

>
> New submission from ?ric Araujo <merwok at netwok.org>:
>
> Hello!  Your bug report gives very little information for us to help you.
> Can you give details such as: your environement / setup, your code,
> expected result and full error message?
>
> https://devguide.python.org/tracker/#reporting-an-issue
>
> ----------
> nosy: +merwok
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31666>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31666>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:36:23 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Oct 2017 09:36:23 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1507541783.52.0.213398074469.issue27172@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Oops, we/I missed the window for also getting the deprecation removed from 3.5.x (as that branch is now in security-fix only mode).

Marking as resolved for 3.6 accordingly.

----------
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27172>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:38:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 09:38:27 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507541907.79.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

I tested PR 3927. I run "./python -m test -j8 -r" with PYTHONSHOWALLOCCOUNT unset: the full Python test suite pass in release and debug modes:

* ./configure CFLAGS="-D COUNT_ALLOCS=1"
* ./configure  --with-pydebug CFLAGS="-D COUNT_ALLOCS=1"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 05:40:53 2017
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 09 Oct 2017 09:40:53 +0000
Subject: [issue31666] Pandas_datareader Error Message - ModuleNotFoundError:
 No module named 'pandas_datareader' with module in folder
In-Reply-To: <1507309056.54.0.213398074469.issue31666@psf.upfronthosting.co.za>
Message-ID: <1507542053.58.0.213398074469.issue31666@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi,

Your bug is related to Pandas and not to Python 3.6.

Maybe you need to post your issue to the bug tracker of Pandas.

You need to install pandas-datareader

pip install pandas-datareader

But it is not an issue with Python.

Have a nice day,

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31666>
_______________________________________

From report at bugs.python.org  Mon Oct  9 06:25:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 10:25:57 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507544757.8.0.213398074469.issue31701@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3903
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 06:31:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 10:31:25 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507545085.12.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

I wrote the PR 3928 to call AddVectoredExceptionHandler(0, ...) rather than AddVectoredExceptionHandler(1, ...), but it doesn't work as expected.

I tested "faulthandler.enable(); faulthandler._sigsegv()": a traceback is logged. But this code tested the *signal handler* rather than the exception handler. I disabled manually the code of faulthandler.enable() to not install signal handlers anymore: no more traceback is logged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 06:52:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 10:52:21 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507546341.92.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

I misunderstood how Windows works. UNIX signals handlers and Windows exception handlers are unrelated. Exception handlers are not called to handle a SIGSEGV signal (raised manually by the process itself, not raised by the Windows kernel).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 07:09:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 11:09:53 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507547393.74.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

I failed to build https://github.com/FynnBe/faulthandler-spam with a Python built myself. But I succeeded to recompile a Python extension (_overlapped) in C++ (I removed two functions which caused compilation error) and then added faulthandler-spam/test_module/module.cpp code into _overlapped. So I was able to test C++ code raising a regular extension called by Python.

Sadly, using "AddVectoredExceptionHandler(0, faulthandler_exc_handler);" (instead of "AddVectoredExceptionHandler(1, ...") doesn't solve the issue: the exception is still logged. It seems like the faulthandler exception handler is called before C++ has the opportunity to handle the exception.

So it doesn't seem possible to log *unhandled* C++ exceptions using AddVectoredExceptionHandler() without flooding logs with *handled* C++ extensions.

I now agree with Steve Dower to ignore *all* C++ exceptions in faulthandler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 07:23:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 11:23:54 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507548234.92.0.213398074469.issue31701@psf.upfronthosting.co.za>


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


----------
pull_requests: +3904

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 07:25:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 11:25:24 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507548324.58.0.213398074469.issue31701@psf.upfronthosting.co.za>


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

I abandon my intent to log all interesting errors: PR 3929 now always ignore all MSC and COM Windows exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 08:11:17 2017
From: report at bugs.python.org (Nicholas Brown)
Date: Mon, 09 Oct 2017 12:11:17 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1507551077.04.0.213398074469.issue10496@psf.upfronthosting.co.za>


Nicholas Brown <nickbroon at gmail.com> added the comment:

This is also a problem when using the DynamicUser=yes feature available in systemd 232 onward with a service that's implemented in python.
See http://0pointer.net/blog/dynamic-users-with-systemd.html for details of the DynamicUser= systemd feature.

----------
nosy: +Nicholas Brown

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon Oct  9 08:26:31 2017
From: report at bugs.python.org (Iryna Shcherbina)
Date: Mon, 09 Oct 2017 12:26:31 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507551991.94.0.213398074469.issue31692@psf.upfronthosting.co.za>


Iryna Shcherbina <shcherbina.iryna at gmail.com> added the comment:

I have run a test build with the patch from PR 3927 applied, and all tests passed.
Full build log can be viewed here: https://kojipkgs.fedoraproject.org//work/tasks/8392/22348392/build.log

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 08:29:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 12:29:21 +0000
Subject: [issue31732] Add TRACE level to the logging module
Message-ID: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

The logging module has already 5 log levels: CRITICAL, ERROR, WARNING, INFO, DEBUG.
https://docs.python.org/dev/library/logging.html#logging-levels
(I don't count NOTSET, I don't consider it to be "usable", at least not in an application or a library.)

For a large application, sometimes we need to a 6th level since DEBUG might be too verbose for some customers (random value: 1 MiB of log per minute). The OpenStack project has 2 additional logging levels: TRACE and AUDIT. See the Oslo Log project used by all OpenStack projects:

https://github.com/openstack/oslo.log/blob/master/oslo_log/handlers.py#L39

The typical usage for TRACE is to log a Python traceback when an exception is logged:

logger.debug("Oops: something bad happened! %s", exc)
for line in my_exception_formatter(exc):
   logger.trace(line)

In software development, "trace" term is commonly associated to "debug traces", as in "How to get debug traces?". Or more commonly in Python: "traceback" or "stack trace".

An additional level helps to filter logs, but also to colorize logs differently.

--

I don't propose to add a new AUDIT level since it's not well defined and it's less popular in OpenStack. For example, the Oslo Log module adds a new logger.trace() method, but no logger.audit().

----------
components: Library (Lib)
messages: 303945
nosy: haypo
priority: normal
severity: normal
status: open
title: Add TRACE level to the logging module
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Mon Oct  9 08:33:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Oct 2017 12:33:04 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507552384.35.0.213398074469.issue31692@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Adding PYTHONSHOWALLOCCOUNT looks rather like a new feature to me. It is on to Bejaming to make a decision about this.

The difference between an environment variable and a command line option is that the former is inherited by children, and the latter is not (this can be considered a drawback or an advantage).

COUNT_ALLOCS is not the only option that spoils Python output. Py_TRACE_REFS adds even more noise to stderr, and this is a default option in debug build. How many tests are still left broken if just change the COUNT_ALLOCS output to stderr instead of stdout?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 08:49:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 12:49:23 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507553363.95.0.213398074469.issue31732@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3905
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Mon Oct  9 08:50:05 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 12:50:05 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507553405.38.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

Attached PR 3930 adds logging.TRACE, logging.trace() and logging.Logger.trace().

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:01:34 2017
From: report at bugs.python.org (Michala)
Date: Mon, 09 Oct 2017 13:01:34 +0000
Subject: [issue31445] Index out of range in get of message.EmailMessage.get()
In-Reply-To: <1505296401.08.0.196475452437.issue31445@psf.upfronthosting.co.za>
Message-ID: <1507554094.81.0.213398074469.issue31445@psf.upfronthosting.co.za>


Michala <muckocucka at gmail.com> added the comment:

I added 2 lines into the file "email/_header_value_parser.py"
into the function "get_mailbox_list(value)" before return value:

    if not value:
        value = ';'
    return mailbox_list, value


It is in attachments.

----------
resolution:  -> works for me
Added file: https://bugs.python.org/file47197/_header_value_parser.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31445>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:10:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:10:29 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507554629.31.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

Other references to a TRACE logging level:

* SaltStack: trace = 5
  https://docs.saltstack.com/en/latest/ref/configuration/logging/#log-levels

* autologging.TRACE = 1: "A custom tracing log level, lower in severity than logging.DEBUG."
  autologging: "Autologging eliminates boilerplate logging setup code and tracing code, and provides a means to separate application logging from program flow and data tracing."
  http://pythonhosted.org/Autologging/autologging.html#autologging.TRACE

* robot.logger.TRACE and robot.logger.trace()
  https://robot-framework.readthedocs.io/en/2.9.2/_modules/robot/api/logger.html
  https://robot-framework.readthedocs.io/en/2.9.2/autodoc/robot.api.html#log-levels

* "I'd like to have loglevel TRACE (5) for my application (...)"
  https://stackoverflow.com/questions/2183233/how-to-add-a-custom-loglevel-to-pythons-logging-facility

--


FYI while searching users of "TRACE" log level, I also found the other log levels:

* "NOTE" < DEBUG
* "FATAL" = CRITICAL
* "profile" = 15 < INFO, but 15 > DEBUG
* "garbage" = 1 < DEBUG

Again, I don't think that these ones are interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:24:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:24:03 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507555443.19.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

More references to TRACE logging level:

* "CUSTOM_TRACE = 5 # Mapping for zLOG.TRACE" in Zope zLOG
  https://github.com/zopefoundation/zLOG/blob/master/src/zLOG/EventLogger.py#L29

* Runlevel = stem.util.enum.UppercaseEnum('TRACE', 'DEBUG', 'INFO', 'NOTICE', 'WARN', 'ERROR')
  TRACE, DEBUG, INFO, NOTICE, WARN, ERR = list(Runlevel)
  https://stem.torproject.org/_modules/stem/util/log.html

* "TRACE = 5 # Trace log level."
  "An extension of Python's option parser."
  https://github.com/mikeorr/WebHelpers2/blob/master/unfinished/logging_optparse.py#L14

* "TRACE = 5"
  http://www.taurus-scada.org/en/latest/_modules/taurus/core/util/log.html

* "TRACE = 9"
  "bokeh: Interactive plots and applications in the browser from Python"
  https://pypkg.com/pypi/bokeh/f/bokeh/util/logconfig.py

* "With custom log levels: (...) TRACE = 5" (an example in the doc)
  https://pypi.python.org/pypi/colorlog

Note: Zope zLOG also has a "CUSTOM_BLATHER = 15 # Mapping for zLOG.BLATHER" level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:32:50 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Oct 2017 13:32:50 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507555970.13.0.213398074469.issue24084@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3906

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:39:56 2017
From: report at bugs.python.org (Mark Wright)
Date: Mon, 09 Oct 2017 13:39:56 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507556396.15.0.213398074469.issue30008@psf.upfronthosting.co.za>


Mark Wright <gienah at gentoo.org> added the comment:

My proposed patch based on python 2.7.14 to remove the use of the API
that was deprecated in openssl 1.1.

----------
keywords: +patch
nosy: +gienah
Added file: https://bugs.python.org/file47198/python-2.7.14-openssl-1.1.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:44:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:44:19 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
Message-ID: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>


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

When Python 2.7 is built in debug mode, it displays the total number of references  when the program finishes or after each statement in the interactive interpreter.

Example:

haypo at selma$ ./python
Python 2.7.14+ (heads/2.7:cc4b6f1c62, Oct  9 2017, 15:30:11) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
2
[45025 refs]
>>> 2+2
4
[45025 refs]
>>> 
[45025 refs]
[21655 refs]

While I'm Python core developer working on reference leaks for years, I *never* used this value. I only use "python -m test -R 3:3 test_xxx" to track reference leaks.

I really liked Python 3.4 which made this option an opt-in, python3 -X showrefcount: bpo-17323 (commit 1f8898a5916b942c86ee8716c37d2db388e7bf2f).

I propose to change Python 2.7 behaviour to not print this value by default, but add a new PYTHONSHOWREFCOUNT environment variable to display it. The value is displayed if PYTHONSHOWREFCOUNT is set. Other similar existing variables:

* PYTHONTHREADDEBUG
* PYTHONDUMPREFS
* PYTHONMALLOCSTATS

https://docs.python.org/2.7/using/cmdline.html#debug-mode-variables

I prefer to add a new environment style rather than adding a new -X command line option. IMHO an environment variable is less intrusive. For example, older Python 2.7 versions completely ignore unknown environment variables, whereas "python2.7 -X showrefcount ..." currently logs the "-X is reserved for implementation-specific arguments" message into stderr.

Attached PR adds PYTHONSHOWREFCOUNT.

----------
messages: 303952
nosy: haypo
priority: normal
severity: normal
status: open
title: [2.7] Add PYTHONSHOWREFCOUNT environment variable to Python 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:44:22 2017
From: report at bugs.python.org (Mark Wright)
Date: Mon, 09 Oct 2017 13:44:22 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507556662.44.0.213398074469.issue30008@psf.upfronthosting.co.za>


Mark Wright <gienah at gentoo.org> added the comment:

This patch allows python 3.4.6 to compile with openssl 1.1 without using
the deprecated API.  It is hacky though as I had to backport changes
that were already in 3.5.4 and 3.6.3.

Also RAND_pseudo_bytes was removed, so I call RAND_bytes instead.

----------
Added file: https://bugs.python.org/file47199/python-3.4.6-openssl-1.1.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:46:17 2017
From: report at bugs.python.org (Mark Wright)
Date: Mon, 09 Oct 2017 13:46:17 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507556777.89.0.213398074469.issue30008@psf.upfronthosting.co.za>


Mark Wright <gienah at gentoo.org> added the comment:

My proposed patch based on python 3.5.4 to remove the use of the API
that was deprecated in openssl 1.1.  As RAND_pseudo_bytes was removed I
call RAND_bytes instead.

----------
Added file: https://bugs.python.org/file47200/python-3.5.4-openssl-1.1.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:46:49 2017
From: report at bugs.python.org (Mark Wright)
Date: Mon, 09 Oct 2017 13:46:49 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507556809.34.0.213398074469.issue30008@psf.upfronthosting.co.za>


Mark Wright <gienah at gentoo.org> added the comment:

My proposed patch based on python 3.6.3 to remove the use of the API
that was deprecated in openssl 1.1.  As RAND_pseudo_bytes was removed I
call RAND_bytes instead.

----------
Added file: https://bugs.python.org/file47201/python-3.6.3-openssl-1.1.0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:47:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:47:29 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1507556849.68.0.213398074469.issue31733@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3907
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:47:56 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:47:56 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1507556876.52.0.213398074469.issue31733@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, ezio.melotti, serhiy.storchaka
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:48:47 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:48:47 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507556927.72.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

Serhiy: "Do you going to backport also -X showrefcount?"

I just created bpo-31733 "Add PYTHONSHOWREFCOUNT environment variable to Python 2.7".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:49:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:49:59 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507556999.39.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

> How many tests are still left broken if just change the COUNT_ALLOCS output to stderr instead of stdout?

That's my first PR: PR 3910.


> COUNT_ALLOCS is not the only option that spoils Python output. Py_TRACE_REFS adds even more noise to stderr, and this is a default option in debug build.

Again, I created bpo-31733 to propose to make this *super annoying* [xxx refs] line *by default*. It makes this issue more consistent ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:54:05 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 09 Oct 2017 13:54:05 +0000
Subject: [issue31734] crash or SystemError in sqlite3.Cache in case it is
 uninitialized or partially initialized
Message-ID: <1507557245.08.0.213398074469.issue31734@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes a crash:
import sqlite3
cache = sqlite3.Cache.__new__(sqlite3.Cache)
cache.get(None)

This is because pysqlite_cache_get() (in Modules/_sqlite/cache.c) assumes that
the Cache object is initialized, and so it passes self->mapping to
PyDict_GetItem(), which assumes it is not NULL, and crashes.


Also, the following code causes a SystemError ('null argument to internal
routine'), as well as refleaks in the deallocation of the Cache object:
import sqlite3
cache = sqlite3.Cache(str)
try:
    cache.__init__()
except TypeError:
    pass
cache.get(None)

This is because pysqlite_cache_init() first sets self->factory to NULL, and
only then parses its arguments, so in case it fails to parse the arguments
(e.g. due to a wrong number of arguments) we are left with a partially
initialized Cache object.


While we are here, we should also fix refleaks that occur when
sqlite3.Cache.__init__() is called more than once.

----------
components: Extension Modules
messages: 303958
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crash or SystemError in sqlite3.Cache in case it is uninitialized or partially initialized
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31734>
_______________________________________

From report at bugs.python.org  Mon Oct  9 09:55:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 13:55:12 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507557312.11.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

(I prefer to not split the discussion on this issue and my 2 PR, I prefer to only discuss the design in this issue.)

https://github.com/python/cpython/pull/3927#pullrequestreview-67963845

Serhiy:
> Using the requires_type_collecting decorator LGTM. But I don't sure about adding PYTHONSHOWALLOCCOUNT. This looks like a new feature to me.
> What if split this PR on two parts? The one fixes issues related to immortal types, the other is about additional output.

Both changes are connected. If you only want to fix tests, that's the purpose of my much longer PR 3910.

"This looks like a new feature to me."

My PR changes the default behaviour, but COUNT_ALLOCS is not enabled by default, not even by the debug mode. You have to explicitely enable it. I expect that developers who use this option are able to track the Python 2.7 changelog and "discover" the newly added environment variable by themself. Moreover, defining PYTHONSHOWALLOCCOUNT=1 is "backward compatible" with Python < 2.7.15 and Python 3, since unknown environment variables are just ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 10:10:43 2017
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 09 Oct 2017 14:10:43 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1507558243.48.0.213398074469.issue27172@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Wait, what is all this nonsense?

inspect.getfullargspec is Python 3 only.  It was added to support keyword-only parameters.  Python 2 doesn't *have* keyword-only parameters, so it isn't needed there.

Check for yourself: Python 2 doesn't have inspect.getfullargspec.

    https://docs.python.org/2/library/inspect.html#inspect.getargspec

We might consider un-deprecating inspect.getargspec() for supporting code supporting Py2 and Py3.  But there's no point in un-deprecating inspect.getfullargspec() for that reason.

Nick: please *back out* your pointless, taffy-headed checkin.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27172>
_______________________________________

From report at bugs.python.org  Mon Oct  9 10:14:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Oct 2017 14:14:40 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1507558480.93.0.213398074469.issue31692@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

All Victor's PRs LGTM is they look good to Benjamin.

But on the next iteration we can get a report that tests don't work if set PYTHONSHOWREFCOUNT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Mon Oct  9 10:27:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 14:27:38 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1507559258.57.0.213398074469.issue31733@psf.upfronthosting.co.za>


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

Since this issue is on the thin border between "feature" and "bug fix", I would like to get the feedback of Benjamin on this change.

@Benjamin: Are you ok to make such change late in the Python 2.7 cycle, in Python 2.7.15?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Mon Oct  9 10:31:25 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 09 Oct 2017 14:31:25 +0000
Subject: [issue31734] crash or SystemError in sqlite3.Cache in case it is
 uninitialized or partially initialized
In-Reply-To: <1507557245.08.0.213398074469.issue31734@psf.upfronthosting.co.za>
Message-ID: <1507559485.42.0.213398074469.issue31734@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Also, the following code results in a memory leak:
import sqlite3
cache = sqlite3.Cache.__new__(sqlite3.Cache)

This is because pysqlite_cache_dealloc() just returns in case of an uninitialized
Cache object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31734>
_______________________________________

From report at bugs.python.org  Mon Oct  9 10:36:56 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Oct 2017 14:36:56 +0000
Subject: [issue31092] delicate behaviour of shared (managed) multiprocessing
 Queues
In-Reply-To: <1501531527.32.0.713819847625.issue31092@psf.upfronthosting.co.za>
Message-ID: <1507559816.23.0.213398074469.issue31092@psf.upfronthosting.co.za>


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

> To a avoid race condition

As Oren explained, the race condition is due to your use of the managed Queue.  If you keep the object alive in the main process until the tasks have finished, there shouldn't be any problem.  The question is: is there any reason you don't want to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31092>
_______________________________________

From report at bugs.python.org  Mon Oct  9 10:55:56 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Oct 2017 14:55:56 +0000
Subject: [issue31681] pkgutil.get_data() leaks open files in Python 2.7
In-Reply-To: <1507059584.22.0.213398074469.issue31681@psf.upfronthosting.co.za>
Message-ID: <1507560956.67.0.213398074469.issue31681@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset cfe1aefcbd2534ddc1059a7332842644e6c8d1e4 by ?ric Araujo (Elvis Pranskevichus) in branch '2.7':
bpo-31681: Make sure pkgutil.get_data closes files properly (#3875)
https://github.com/python/cpython/commit/cfe1aefcbd2534ddc1059a7332842644e6c8d1e4


----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31681>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:00:26 2017
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Oct 2017 15:00:26 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507561226.08.0.213398074469.issue30008@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +3908
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:00:43 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:00:43 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507561243.8.0.213398074469.issue24084@psf.upfronthosting.co.za>


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

Hum, "2447?s" makes the output more difficult to parse (by a program) and to read (by a human). Why not always displaying 6 digits (after the dot) for the two "percall" columns.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:03:13 2017
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Oct 2017 15:03:13 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507561393.54.0.213398074469.issue30008@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for your patches, Mark. A few remarks:

Python 3.5 is in security fix-only mode. The issue is not a security bug.

Python has switched to a different workflow a while ago. Please provide a pull request on GitHub against master (3.7). I'll take care of the backports.

Also your implementation of version specific TLS has multiple flaws, e.g. missing NULL check and missing set_max_proto_version() calls. I opened a new PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:04:44 2017
From: report at bugs.python.org (Paul Pinterits)
Date: Mon, 09 Oct 2017 15:04:44 +0000
Subject: [issue31735] Documentation incorrectly states how descriptors are
 invoked
Message-ID: <1507561484.86.0.213398074469.issue31735@psf.upfronthosting.co.za>


New submission from Paul Pinterits <rawing7 at gmail.com>:

The [descriptor howto](https://docs.python.org/3/howto/descriptor.html#invoking-descriptors) states:

"For example, obj.d looks up d in the dictionary of obj. If d defines the method __get__(), then d.__get__(obj) is invoked [...]"

This is not true - the descriptor obtained from obj's dictionary is never invoked. If it was, the following two snippets would produce output:


class Class:
    pass

obj = Class()
obj.__dict__['d'] = property(lambda: print('called'))

_ = obj.d  # nothing is printed.


class Obj:
    @property
    def d(self):
        print('called')

_ = Obj.d  # nothing is printed.

----------
assignee: docs at python
components: Documentation
messages: 303968
nosy: Paul Pinterits, docs at python
priority: normal
severity: normal
status: open
title: Documentation incorrectly states how descriptors are invoked
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31735>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:06:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:06:21 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
In-Reply-To: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>
Message-ID: <1507561581.16.0.213398074469.issue31723@psf.upfronthosting.co.za>


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


New changeset c0cabc23bbe474d542ff8a4f1243f4ec3cce5549 by Victor Stinner (Oren Milman) in branch 'master':
bpo-31723: Fix refleaks when zipimporter.__init__() is called more than once (GH-3919)
https://github.com/python/cpython/commit/c0cabc23bbe474d542ff8a4f1243f4ec3cce5549


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:07:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:07:07 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
In-Reply-To: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>
Message-ID: <1507561627.4.0.213398074469.issue31723@psf.upfronthosting.co.za>


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

> The following code causes refleaks:

I'm curious, how did you find this code? Are you using a code generator coupled with a tool to track for reference leaks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:08:00 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:08:00 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
In-Reply-To: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>
Message-ID: <1507561680.57.0.213398074469.issue31723@psf.upfronthosting.co.za>


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

I merged your PR, thanks! As I wrote on the PR:

I don't think that a NEWS entry is needed, since you are not supposed to call __init__() multiple times.

I don't think that it's worth it to backport the fix to Python 2.7 and 3.6. So I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:09:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:09:55 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
In-Reply-To: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>
Message-ID: <1507561795.14.0.213398074469.issue31723@psf.upfronthosting.co.za>


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

> I'm curious, how did you find this code? Are you using a code generator coupled with a tool to track for reference leaks?

Oh, I think that the issue is related to bpo-31718.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:09:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Oct 2017 15:09:56 +0000
Subject: [issue31734] crash or SystemError in sqlite3.Cache in case it is
 uninitialized or partially initialized
In-Reply-To: <1507557245.08.0.213398074469.issue31734@psf.upfronthosting.co.za>
Message-ID: <1507561796.43.0.213398074469.issue31734@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ghaering, serhiy.storchaka
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31734>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:14:07 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 09 Oct 2017 15:14:07 +0000
Subject: [issue31723] refleaks in zipimport when calling
 zipimporter.__init__() more than once
In-Reply-To: <1507390047.35.0.213398074469.issue31723@psf.upfronthosting.co.za>
Message-ID: <1507562047.36.0.213398074469.issue31723@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Yes, i am going manually over the code to find similar stuff to #31718,
and i afraid i found quite a few, and still working on it..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31723>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:20:23 2017
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Mon, 09 Oct 2017 15:20:23 +0000
Subject: [issue31734] crash or SystemError in sqlite3.Cache in case it is
 uninitialized or partially initialized
In-Reply-To: <1507557245.08.0.213398074469.issue31734@psf.upfronthosting.co.za>
Message-ID: <1507562423.27.0.213398074469.issue31734@psf.upfronthosting.co.za>


Change by Eric N. Vander Weele <ericvw at gmail.com>:


----------
nosy: +ericvw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31734>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:22:09 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Oct 2017 15:22:09 +0000
Subject: [issue31681] pkgutil.get_data() leaks open files in Python 2.7
In-Reply-To: <1507059584.22.0.213398074469.issue31681@psf.upfronthosting.co.za>
Message-ID: <1507562529.95.0.213398074469.issue31681@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31681>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:23:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:23:29 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507562609.0.0.213398074469.issue31705@psf.upfronthosting.co.za>


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

> The issue is reproducible on a CentOS 7.4 on ppc64le architecture.

What is the kernel version?

It would be nice to have the strace output. Example:

strace -o trace ./python -m test -v test_socket -m test_sha256
# then get the trace file

I'm surprised because it seems like ENOKEY (error 126) can only be get on accept(), not on send():
http://elixir.free-electrons.com/linux/latest/source/crypto/af_alg.c#L295

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:25:14 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 09 Oct 2017 15:25:14 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507562714.22.0.213398074469.issue31705@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Forgot the mention the kernel version which is 3.10.0-693.2.1.el7.ppc64le

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:28:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:28:12 +0000
Subject: [issue29324] test_aead_aes_gcm fails on Kernel 4.9
In-Reply-To: <1484838066.61.0.93462051202.issue29324@psf.upfronthosting.co.za>
Message-ID: <1507562892.03.0.213398074469.issue29324@psf.upfronthosting.co.za>


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

FYI the merged fix is:

commit 9764c151c51480a7ca6042b1ccd69be2620ff360
Author: matejcik <matejcik at gmail.com>
Date:   Thu Feb 16 14:41:31 2017 +0100

    update test_socket AEAD test for kernel 4.9 and up (#133)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29324>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:30:56 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Oct 2017 15:30:56 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507563056.98.0.213398074469.issue31701@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> Is it possible to be asked to be called as the last handler ...

Unfortunately not, since the stack-based handlers always come after the vector handlers, and C++ handlers written using try/catch will always be stack-based.

It may be interesting for faulthandler to have a stack-based version, so that you can provide the function to call and it will call it inside an exception handler. But I don't think it's that interesting and in any case doesn't need to be in the stdlib.

I wouldn't worry about 0xE0434F4D for now, but if someone comes along with a need for it then we can add it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:50:39 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Mon, 09 Oct 2017 15:50:39 +0000
Subject: [issue31735] Documentation incorrectly states how descriptors are
 invoked
In-Reply-To: <1507561484.86.0.213398074469.issue31735@psf.upfronthosting.co.za>
Message-ID: <1507564239.8.0.213398074469.issue31735@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

You get what you should get: when you print obj.d, Obj.d, you will get:

<property object at 0xDEADBEEF>

which is exactly what you expect:
- in the first case, you assigned a property object to the dictionary at obj.__dict__, so that's what you get back when you run obj.d.
- you defined a property on a class called d, and you get it when you run Obj.d

If you run print(Obj().d) you will get a TypeError: your lambda should read:

lambda self: print('called')

Properties should be added to the class not the instance, see https://stackoverflow.com/questions/1325673/how-to-add-property-to-a-class-dynamically and https://eev.ee/blog/2012/05/23/python-faq-descriptors/

----------
nosy: +Henk-Jaap Wagenaar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31735>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:52:41 2017
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Oct 2017 15:52:41 +0000
Subject: [issue31727] FTP_TLS errors when
In-Reply-To: <1507482521.5.0.213398074469.issue31727@psf.upfronthosting.co.za>
Message-ID: <1507564361.24.0.213398074469.issue31727@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

"OSError: [Errno 0] Error" typically means that OpenSSL failed due to a Windows error, but we assumed it failed due to a POSIX error and so read the wrong error number (errno instead of GetLastError()).

It's worth testing with Python 3.7.0a1, since we made some changes to OpenSSL integration (as well as updating it to a significantly newer version) that may impact this scenario.

----------
assignee:  -> christian.heimes
components: +SSL
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31727>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:54:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:54:52 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507564492.13.0.213398074469.issue31178@psf.upfronthosting.co.za>


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

commit fae0512e58619231a566bf77aa21148440b0ec8d
Author: Miss Islington (bot) <31488909+miss-islington at users.noreply.github.com>
Date:   Thu Oct 5 07:10:59 2017 -0700

    [3.6] bpo-31178: Mock os.waitpid() in test_subprocess (GH-3896) (#3897)
    
    Fix test_exception_errpipe_bad_data() and
    test_exception_errpipe_normal() of test_subprocess: mock os.waitpid()
    to avoid calling the real os.waitpid(0, 0) which is an unexpected
    side effect of the test.
    (cherry picked from commit 11045c9d8a21dd9bd182a3939189db02815f9783)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:55:17 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 15:55:17 +0000
Subject: [issue31178] [EASY] subprocess: TypeError: can't concat str to bytes, 
 in _execute_child()
In-Reply-To: <1502378984.02.0.493180637871.issue31178@psf.upfronthosting.co.za>
Message-ID: <1507564517.41.0.213398074469.issue31178@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31178>
_______________________________________

From report at bugs.python.org  Mon Oct  9 11:58:38 2017
From: report at bugs.python.org (Romuald Brunet)
Date: Mon, 09 Oct 2017 15:58:38 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507564718.8.0.213398074469.issue24084@psf.upfronthosting.co.za>


Romuald Brunet <romuald.brunet at gmail.com> added the comment:

I figured we didn't want to change the size of the columns (+12 COL), but this could easily be done yes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Mon Oct  9 12:06:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 16:06:26 +0000
Subject: [issue31683] a stack overflow on windows in
 faulthandler._fatal_error()
In-Reply-To: <1507066812.21.0.213398074469.issue31683@psf.upfronthosting.co.za>
Message-ID: <1507565186.96.0.213398074469.issue31683@psf.upfronthosting.co.za>


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

IMHO this issue is theorical. I don't expect that anyone would call Py_FatalError() with a very long message, so I will not backport the fix to Python 2.7 and 3.6.

Thanks for the bug report Oren Milman!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31683>
_______________________________________

From report at bugs.python.org  Mon Oct  9 12:21:50 2017
From: report at bugs.python.org (Tim Graham)
Date: Mon, 09 Oct 2017 16:21:50 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1507566110.97.0.213398074469.issue27172@psf.upfronthosting.co.za>


Tim Graham <timograham at gmail.com> added the comment:

Perhaps the reason for the undeprecation could use some clarification. In a Python 3 only world (where Django's master branch is), I believe there's still usefulness for inspect.getfullargspec() -- see https://github.com/django/django/search?q=getfullargspec for usages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27172>
_______________________________________

From report at bugs.python.org  Mon Oct  9 12:44:41 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 16:44:41 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507567481.23.0.213398074469.issue31415@psf.upfronthosting.co.za>


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


----------
pull_requests: +3910
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Mon Oct  9 12:47:05 2017
From: report at bugs.python.org (Paul Pinterits)
Date: Mon, 09 Oct 2017 16:47:05 +0000
Subject: [issue31735] Documentation incorrectly states how descriptors are
 invoked
In-Reply-To: <1507561484.86.0.213398074469.issue31735@psf.upfronthosting.co.za>
Message-ID: <1507567625.24.0.213398074469.issue31735@psf.upfronthosting.co.za>


Paul Pinterits <rawing7 at gmail.com> added the comment:

I'm aware that descriptors have to exist on the class in order to work. The point is that the documentation states "If d defines the method __get__(), then d.__get__(obj) is invoked" (where d is obj.d), which is simply not true.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31735>
_______________________________________

From report at bugs.python.org  Mon Oct  9 12:52:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Oct 2017 16:52:34 +0000
Subject: [issue31701] faulthandler dumps 'Windows fatal exception: code
 0xe06d7363'
In-Reply-To: <1507197551.3.0.213398074469.issue31701@psf.upfronthosting.co.za>
Message-ID: <1507567954.8.0.213398074469.issue31701@psf.upfronthosting.co.za>


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


New changeset 6e3d6b5dc22cd06d8c4d44a38a8a3415e4bebb16 by Victor Stinner in branch 'master':
bpo-31701: faulthandler: ignore MSC and COM Windows exception (#3929)
https://github.com/python/cpython/commit/6e3d6b5dc22cd06d8c4d44a38a8a3415e4bebb16


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________

From report at bugs.python.org  Mon Oct  9 12:55:22 2017
From: report at bugs.python.org (Paul Pinterits)
Date: Mon, 09 Oct 2017 16:55:22 +0000
Subject: [issue31735] Documentation incorrectly states how descriptors are
 invoked
In-Reply-To: <1507561484.86.0.213398074469.issue31735@psf.upfronthosting.co.za>
Message-ID: <1507568122.35.0.213398074469.issue31735@psf.upfronthosting.co.za>


Paul Pinterits <rawing7 at gmail.com> added the comment:

If we take this class:

class Obj:
    @property
    def d(self):
        print('called')

And we access Obj.d:

_ = Obj.d

According to the docs, the following should happen:

# obj.d looks up d in the dictionary of obj
d = Obj.__dict__['d']

# If d defines the method __get__(),
if hasattr(d, '__get__'):

    # then d.__get__(obj) is invoked
    d.__get__(Obj)

We know this doesn't happen because nothing is printed to stdout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31735>
_______________________________________

From report at bugs.python.org  Mon Oct  9 13:11:10 2017
From: report at bugs.python.org (Ben Bolker)
Date: Mon, 09 Oct 2017 17:11:10 +0000
Subject: [issue31736] PEP 485 tiny typo
Message-ID: <1507569070.77.0.213398074469.issue31736@psf.upfronthosting.co.za>


New submission from Ben Bolker <bbolker at gmail.com>:

In two places in https://www.python.org/dev/peps/pep-0485/ floating point numbers are incorrectly formatted: 1-e8 and 1-e9 rather than 1e-8 and 1e-9 ("absolute tolerance default", para. 3 and "relative tolerance default", para. 1)

----------
messages: 303987
nosy: bbolker
priority: normal
severity: normal
status: open
title: PEP 485 tiny typo
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31736>
_______________________________________

From report at bugs.python.org  Mon Oct  9 13:49:43 2017
From: report at bugs.python.org (Richard Gibson)
Date: Mon, 09 Oct 2017 17:49:43 +0000
Subject: [issue31737] Documentation renders incorrectly
Message-ID: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>


New submission from Richard Gibson <richard.gibson at gmail.com>:

The content at docs.python.org seems to be inserting language-dependent "smart quotes" in code blocks, which mangles backslashes and sequences like `'''`. Observed at https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals , which renders

  longstring      ::=  ???? longstringitem* ???? | ????? longstringitem* ?????

instead of

  longstring      ::=  "'''" longstringitem* "'''" | '"""' longstringitem* '"""'

and

  stringescapeseq ::=  ?" <any source character>

instead of

  stringescapeseq ::=  "\" <any source character>

, and looks even worse in other languages:

  longstring      ::=   ? ?? ? longstringitem*  ? ?? ? | ? ??  ?? longstringitem* ? ??  ??

  longstring      ::=  ???? longstringitem* ???? | ????? longstringitem* ?????


Running `make html` locally produces the desired output, so whatever's going on appears specific to the public site.

----------
assignee: docs at python
components: Documentation
messages: 303988
nosy: docs at python, gibson042
priority: normal
severity: normal
status: open
title: Documentation renders incorrectly
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31737>
_______________________________________

From report at bugs.python.org  Mon Oct  9 13:52:27 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Oct 2017 17:52:27 +0000
Subject: [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1507571547.07.0.213398074469.issue31737@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31737>
_______________________________________

From report at bugs.python.org  Mon Oct  9 14:06:22 2017
From: report at bugs.python.org (Liel Fridman)
Date: Mon, 09 Oct 2017 18:06:22 +0000
Subject: [issue31738] Lib/site.py: method `abs_paths` is not documented
Message-ID: <1507572382.24.0.213398074469.issue31738@psf.upfronthosting.co.za>


Change by Liel Fridman <lielft at gmail.com>:


----------
components: Tests
nosy: lielfr
priority: normal
severity: normal
status: open
title: Lib/site.py: method `abs_paths` is not documented
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31738>
_______________________________________

From report at bugs.python.org  Mon Oct  9 14:11:25 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 09 Oct 2017 18:11:25 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507572685.62.0.213398074469.issue31705@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Attaching the strace output.

----------
Added file: https://bugs.python.org/file47202/trace

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Mon Oct  9 14:38:11 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 09 Oct 2017 18:38:11 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1504175392.51.0.871887341171.issue31314@psf.upfronthosting.co.za>
Message-ID: <1507574291.15.0.213398074469.issue31314@psf.upfronthosting.co.za>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +3911
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:02:39 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 09 Oct 2017 19:02:39 +0000
Subject: [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1507575759.84.0.213398074469.issue31737@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

We spotted some quoting probleme in the french translation too, and I still didn't had time to look at it, typically here: https://docs.python.org/fr/3/library/itertools.html#itertool-functions

where we're getting:

  10.1.1. Fonctions d?itertool?

instead of:

  10.1.1. Fonctions d'itertool?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31737>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:04:38 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 09 Oct 2017 19:04:38 +0000
Subject: [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1507575878.15.0.213398074469.issue31584@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

FTR I'm still daily monitoring the presence of mixed-up pages server side and did not spotted a single one.

I'm still using my very basic:

  $ grep -rl 'd?finition' /srv/docs.python.org/ja/; grep -rl ? /srv/docs.python.org/{2.7,3.6,3.7}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:10:20 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 09 Oct 2017 19:10:20 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1507576220.5.0.213398074469.issue26546@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

? https://docs.python.org/fr/

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:27:58 2017
From: report at bugs.python.org (Nathaniel Manista)
Date: Mon, 09 Oct 2017 19:27:58 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
Message-ID: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

https://docs.python.org/3.7/library/socket.html#socket.socket.close says "it is recommended to close() [sockets] explicitly, or to use a with statement around them", but in the example code on the same page at https://docs.python.org/3.7/library/socket.html#example correct use of the .close() method seems to be missing.

----------
assignee: docs at python
components: Documentation
messages: 303993
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: socket.close recommended but not demonstrated in same-page example code
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:31:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Oct 2017 19:31:45 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507577505.4.0.213398074469.issue31719@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Why not use just abort() or Py_FatalError()?

$ ./python -c 'import ctypes; ctypes.CDLL("libc.so.6").abort()'
Aborted (core dumped)

$ ./python -c 'import ctypes; ctypes.pythonapi.Py_FatalError(b"boom!")'
Fatal Python error: boom!

Current thread 0x00007f26805c7580 (most recent call first):
  File "<string>", line 1 in <module>
Aborted (core dumped)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:32:36 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Oct 2017 19:32:36 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1507577556.08.0.213398074469.issue31739@psf.upfronthosting.co.za>


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

Which example?  (It might be easiest to just generate a PR with your suggested improvement.)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:40:26 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 09 Oct 2017 19:40:26 +0000
Subject: [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1507578026.49.0.213398074469.issue31737@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Tested locally with different versions of sphinx-build:

- 1.3.3 does not produce the issue
- 1.6.2 (used on docs.python.org) produces the issue
- 1.6.3 does not produce the issue
- 1.6.4 does not produce the issue

Reading the changelog between 1.6.2 and 1.6.3 lead to https://github.com/sphinx-doc/sphinx/issues/3824 itself leading to
https://github.com/sphinx-doc/sphinx/commit/f99fe20e507210bd7db8665b8f234f1fe25c8100

So it looks fixed in 1.6.3 and 1.6.4, I'm running a full local build (using docsbuild-scripts) using sphinx 1.6.4 to see if we can upgrade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31737>
_______________________________________

From report at bugs.python.org  Mon Oct  9 15:56:10 2017
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Oct 2017 19:56:10 +0000
Subject: [issue31724] test_xmlrpc_net should use something other than
 buildbot.python.org
In-Reply-To: <1507441441.34.0.213398074469.issue31724@psf.upfronthosting.co.za>
Message-ID: <1507578970.63.0.213398074469.issue31724@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31724>
_______________________________________

From report at bugs.python.org  Mon Oct  9 16:04:48 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 09 Oct 2017 20:04:48 +0000
Subject: [issue31734] crash or SystemError in sqlite3.Cache in case it is
 uninitialized or partially initialized
In-Reply-To: <1507557245.08.0.213398074469.issue31734@psf.upfronthosting.co.za>
Message-ID: <1507579488.66.0.213398074469.issue31734@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3912
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31734>
_______________________________________

From report at bugs.python.org  Mon Oct  9 16:32:17 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 09 Oct 2017 20:32:17 +0000
Subject: [issue31740] refleaks when calling sqlite3.Connection.__init__() more
 than once
Message-ID: <1507581137.79.0.213398074469.issue31740@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes refleaks:
import sqlite3
connection = sqlite3.Connection.__new__(sqlite3.Connection)
connection.__init__('foo')
connection.__init__('foo')

This is because pysqlite_connection_init() (in Modules/_sqlite/connection.c)
doesn't decref (if needed) before assigning to various fields of `self`.

I would open a PR to fix this soon.

----------
components: Extension Modules
messages: 303997
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: refleaks when calling sqlite3.Connection.__init__() more than once
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31740>
_______________________________________

From report at bugs.python.org  Mon Oct  9 16:35:03 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 09 Oct 2017 20:35:03 +0000
Subject: [issue31738] Lib/site.py: method `abs_paths` is not documented
Message-ID: <1507581303.97.0.213398074469.issue31738@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

Hi, thanks for reporting.

This method has been renamed in https://github.com/python/cpython/commit/28a691b7fdde1b8abafa4c4a5025e6bfa44f48b9 and is only used in Lib/site.py (currently in main()).

The function has a docstring, so:

  Help on function abs_paths in module site:

  abs_paths()
      Set all module __file__ and __cached__ attributes to an absolute path


Is this function usefull for you outside of site.py?

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31738>
_______________________________________

From report at bugs.python.org  Mon Oct  9 16:52:28 2017
From: report at bugs.python.org (Oren Milman)
Date: Mon, 09 Oct 2017 20:52:28 +0000
Subject: [issue31740] refleaks when calling sqlite3.Connection.__init__() more
 than once
In-Reply-To: <1507581137.79.0.213398074469.issue31740@psf.upfronthosting.co.za>
Message-ID: <1507582348.27.0.213398074469.issue31740@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Ah, here also there are crashes when calling methods of uninitialized connection objects.

Should i fix this as part of this issue, or open another one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31740>
_______________________________________

From report at bugs.python.org  Mon Oct  9 16:53:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Oct 2017 20:53:19 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1507582399.98.0.213398074469.issue31608@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I meant that if make deque.copy(), deque.__add__() and deque.__mul__() returning an exact deque for subclasses, this would make the deque class more consistent with other collections and solve this issue. This could even make them (almost) atomic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Mon Oct  9 17:48:05 2017
From: report at bugs.python.org (Chris Caron)
Date: Mon, 09 Oct 2017 21:48:05 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
Message-ID: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>


New submission from Chris Caron <lead2gold at gmail.com>:

The Windows install of Python 2.7.13 defaults it's install into **C:\Python27**.  It creates several subdirectories within this; one of which is **C:\Python27\lib\site-packages\backports**. So just out of the box (without this script installed):
```python
import backports
print(backports.__path__)
# C:\Python27\lib\site-packages\backports
```

I have a custom package that sets the sys.path(0, "new path") entry which works great in Linux. I ship all my modules and settings in this path.  This to work great in Windows too 'except' for the reference to `backports`.

Consider the block of code:
```python
import sys
from os import getcwd
from os.path import join
sys.path.insert(0, join(getcwd(), 'MyLibraries'))

# Now if we import backports, we should find the one in our MyLibraries directory
import backports
print(backports.__path__)    # Nope... :(
# C:\Python27\lib\site-packages\backports

# What's weird is it's not entirely broken... you can do the following:
import chardet
print(chardet.__path__)
# Prints my path to MyLibraries/chardet
# So the path is correct and other libraries are coming in correctly
```

What's really weird, is (in Windows) even if i delete the **C:\Python27\lib\site-packages\backports**, it still imports the module; so it's like part of the Python27 build in some way.

`pip install` with the backports module I want works great because it drops the correct package in this 'lib/site-packages\backports' directory which is constantly being referenced.

>From what I can see the Microsoft version of Python27 can't seem to stop referencing (even when told not to) the _backports_ location. Linux works perfectly (as intended) but having customers port to this isn't an option for me.

----------
components: Windows
messages: 304001
nosy: Chris Caron, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: backports import path can not be overridden in Windows (Linux works fine)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Mon Oct  9 18:01:35 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Oct 2017 22:01:35 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507586495.74.0.213398074469.issue31741@psf.upfronthosting.co.za>


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

Where did you get your installer?  I don't find any references to 'backports' in our repo, other than a couple of places in the docs where the word appears.

I also don't understand the relationship between your MyPackages and a backports directory.  They seem to be unrelated in your examples.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Mon Oct  9 18:18:09 2017
From: report at bugs.python.org (Chris Caron)
Date: Mon, 09 Oct 2017 22:18:09 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507586495.74.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <CAAQMMo2bc207jSO31iZ+1WUpgsVTY4LixWHs7qhj4x-CvBdmJA@mail.gmail.com>


Chris Caron <lead2gold at gmail.com> added the comment:

Thank you for replying so quickly;  the issue stems from a bug created here
which explains it a bit better:
https://github.com/caronc/nzb-notify/issues/27 (scroll to the bottom).

In my case, I had a lib\site-packages\backports in C:\Python27 that keeps
over-riding the one defined in the \MyLibraries path. But even when the
'sys.path' has been successfully overridden, the backports module (one i
provide for the package of interest) keeps reverting to the
C:\Python27\lib\site-packages\ path.  It actually just throws an exception
that the module doesn't exist (when ordering of paths would say it does).

To answer your other question: I got the installer from here:
https://www.python.org/downloads/release/python-2713/ (the MSI 64 bit
installer - second from the bottom)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Mon Oct  9 20:09:22 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Oct 2017 00:09:22 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507594162.78.0.213398074469.issue31741@psf.upfronthosting.co.za>


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

What is "the backports module"?  I still don't understand what a backports directory, that I don't think our installer creates, has to do with your MyLibraries directory.

I'm sorry that I'm having trouble following your explanation.  Maybe you could list out the contents of your directories and what your sys.path is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Mon Oct  9 20:40:08 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 10 Oct 2017 00:40:08 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1504175392.51.0.871887341171.issue31314@psf.upfronthosting.co.za>
Message-ID: <1507596008.55.0.213398074469.issue31314@psf.upfronthosting.co.za>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I sent a patch if anyone have a time, please take a look :)

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Mon Oct  9 21:47:27 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 01:47:27 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
Message-ID: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Chatting to Donald Stufft and Amber Brown about the way we currently handle provisional APIs, I think they have a legitimate concern that we may not be gathering adequately informed consent from users when they depend on APIs that we've reserved the right to change in the future.

So what I'm now wondering is whether or not it may be worth amending PEP 411 to say that all provisional modules should include an import-time snippet like the following:

    import __main__
    if not getattr(__main__, f"use_provisional_{__name__}"):
        import warnings
        warnings.warn(FutureWarning, f"The {__name__} module is currently a provisional API. New features might be added and API may change even between minor releases if deemed necessary.")

The exact wording of the warning would match the caveat used in that module's API documentation (the variant above comes from the "typing" module)

The idea here would be that *application* developers would get a FutureWarning whenever a provisional module was imported, unless they set "use_provisional_<module>" in __main__.

Storing the marker attribute in __main__ would be intended to serve two purposes:

- it's always going to be imported anyway, so the runtime cost of the new snippet in the provisional modules will be low
- it sends a clear indication to library authors that they *shouldn't* be setting the flag implicitly as a side-effect of import (framework authors, by contrast, may decide to set it, since they're more in control of the overall application behaviour than library authors)

----------
messages: 304006
nosy: dstufft, gvanrossum, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Default to emitting FutureWarning for provisional APIs
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Mon Oct  9 21:50:02 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 01:50:02 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507600202.96.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Another advantage of this approach: anyone running their tests in a "no warnings allowed" configuration would get a hard failure when dependencies on a provisional API were unexpectedly introduced (e.g. when updating a third party library), rather than silently acquiring a potential future compatibility issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Mon Oct  9 21:53:30 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 01:53:30 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507600410.72.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is also fairly similar to Rust's approach of using feature flags to explicitly opt-in to unstable features: https://doc.rust-lang.org/unstable-book/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Mon Oct  9 23:58:29 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Oct 2017 03:58:29 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507607909.55.0.213398074469.issue31742@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

While I understand the sentiment, having this warning pop up every time you import a provisional module while developing code feels like harassment of the very users we'd like to try out the provisional APIs.

It's also too course-grained -- most of the time a provisional module is pretty stable but has a few gray areas that are still under development.

For those people who are writing software for the ages, maybe this can be an opt-in warning? I won't object to that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 00:24:28 2017
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 10 Oct 2017 04:24:28 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507609468.42.0.213398074469.issue31742@psf.upfronthosting.co.za>


Donald Stufft <donald at stufft.io> added the comment:

The fundamental problem is that unless you're closely following the development of python-dev, it's really really easy to use a provisional module without knowing that you are.

Take asyncio for example, as far as I can tell the documentation that noted it was provisional was a single, near invisible (light grey on a white background) call out at the very top of a single page in the documentation. This is made especially hard when you have people giving talks at PyCon encouraging people to use this, libraries of the code that don't mention that asyncio is provisional, so unless you're directly using asyncio you might not even be aware that they're using a provisional API at all.

This has the effect that by including these APIs and make the fact they are provisional practically unnoticeable, it pushes the pain of dealing with changes onto library authors who have their own users asking them to integrate with these features. Putting library authors in the position of either having to opt-in to a provisional API and hope it doesn't change, having to scramble to keep up with changes in new minor releases, or having to relitigate why they're not going to support a provisional API.

Ironically, as we found with web APIs, releasing provisional APIs can actually make things worse for end users, because people will expect the usage of the APIs as if they were covered under the normal contract, but the developers of those APIs feel empowered to make more drastic changes. The long development time of CPython makes this even worse (it was ~2 years from the release of 3.4.0 and 3.6.0 for asyncio to become non provisional, longer if you count alpha/beta/etc) because people want to use the new stuff, but they have to wait a fairly long time to be "allowed" to do it, all the while the general ecosystem consensus is "just do it and ignore the warning, if you noticed the warning at all".

Ultimately, the provisional status doesn't reduce the pain of getting APIs wrong, it just shifts the pain from CPython's developers to the software developers writing stuff that depends on CPython but that they don't directly control the execution environment (e.g., all the OSS libraries and applications on PyPI). A proposal like this helps alleviate some of that pain by creating additional barriers to entry to make end users less likely to use it unless they understand what they're asking for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 00:57:15 2017
From: report at bugs.python.org (Amber Brown)
Date: Tue, 10 Oct 2017 04:57:15 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507611435.57.0.213398074469.issue31742@psf.upfronthosting.co.za>


Amber Brown <hawkowl at atleastfornow.net> added the comment:

Donald hits it on the head for me.

As long as the code is not covered by the same API deprecation contract that the rest of the standard library is, it should make it obvious when attempting to use it. I can be relatively certain that a lot of people were not aware that the potential scope of asyncio changes included what it potentially could have, and I personally wasn't aware that typing was a provisional module (and got burnt by incompatible changes in 3.6). There was a small note in the docs, but when I was learning from cattrs's docs and not CPython's, how was I supposed to know?

A warning is low cost, there's a way to switch it off, and it potentially informs users that they need to be aware of its provisional status, especially if it's a dependency of a dependency.

----------
nosy: +hawkowl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 01:28:52 2017
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 10 Oct 2017 05:28:52 +0000
Subject: [issue31736] PEP 485 tiny typo
In-Reply-To: <1507569070.77.0.213398074469.issue31736@psf.upfronthosting.co.za>
Message-ID: <1507613332.39.0.213398074469.issue31736@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the report. Fixed in https://github.com/python/peps/commit/070dc7e037e5f66e4e17b661641503815a8bbe05

(By the way, you can report issues like this at https://github.com/python/peps/issues or send a PR directly.)

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31736>
_______________________________________

From report at bugs.python.org  Tue Oct 10 01:34:07 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 10 Oct 2017 05:34:07 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507613647.9.0.213398074469.issue31728@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

As serhiy pointed out in a comment in PR 3924, setting self->text or self->tail to
NULL might lead to an assertion failure, so we should also prevent the following
assertion failure (and the similar one for tail):
import xml.etree.ElementTree
class X:
    def __del__(self):
        elem.text
        
elem = xml.etree.ElementTree.Element('elem')
elem.text = X()
elem.__setstate__({'tag': None}) # implicitly also set elem.text to None

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Tue Oct 10 01:35:13 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 10 Oct 2017 05:35:13 +0000
Subject: [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1507613713.16.0.213398074469.issue31584@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Japanese HTML has this line:

    <link rel="canonical" href="https://docs.python.org/2/faq/design.html" />

I suspect this line affects CDN's cache.
But I can't find document about canonical link in fastly's document.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Tue Oct 10 02:05:50 2017
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 10 Oct 2017 06:05:50 +0000
Subject: [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1507615550.24.0.213398074469.issue31584@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

https://twitter.com/miyagawa/status/917629042278359040

Miyagawa-san, the member of Fastly told me they doesn't use HTML
content for cache key, unless we customize VCL.

But I can't find VCL for docs.python.org in github.com/python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Tue Oct 10 02:10:12 2017
From: report at bugs.python.org (Julien Palard)
Date: Tue, 10 Oct 2017 06:10:12 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507615812.24.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Today I tried without utf8x and an up-to-date version of texlive, errors looked less mystical, so I was able to open a readable / easy to reproduce issue:

https://github.com/sphinx-doc/sphinx/issues/4136

I then followed the idea of trying xetex and I was able to build english and french PDF (still not had time to try japanese).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct 10 02:14:15 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Oct 2017 06:14:15 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1507616055.06.0.213398074469.issue31589@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +3913
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct 10 02:17:56 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 06:17:56 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1507616276.27.0.213398074469.issue27172@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Larry, your personal insult is entirely unwelcome, unnecessary, and unappreciated, especially as it's wrong regarding the Python 2/3 compatibility concerns.

While getfullargspec() is indeed new in Python 3.x, it's also deliberately designed as a *drop-in replacement* for inspect.getargspec(). This means straddling Python 2 & 3 is straightforward, since you just need to toggle which API function you call (getargspec() on 2.7, getfullargspec() on 3.x).

This is *not* the case for switching to the inspect.signature() API: doing that for existing code that still supports Python 2.7 also requires switching to one of the third party backports of that API to 2.7, and then changing the way your own code models function signatures.

This is why getfullargspec() only received a documented deprecation, rather than a programmatic one. However, the combination of that notice in the documentation with the programmatic deprecation warning in getargspec() was enough to make people believe that in order to add Python 3 support, they *also* had to either switch to the inspect.signature() API, or else write and maintain their own version of getfullargspec().

That wasn't the intended outcome, and we have no plans to actually remove getfullargspec(), so I changed the wording in the getargspec() deprecation warning and the getfullargspec() documentation to better encourage the desired behaviour (i.e. inspect.signature() being used in new code, and existing code being migrated to the inspect.signature() API as developers find value in doing so)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27172>
_______________________________________

From report at bugs.python.org  Tue Oct 10 02:29:48 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 06:29:48 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1507616988.4.0.213398074469.issue27172@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note: the minor incompatibility that required getfullargspec() to be a separate API in the first place is the fact that it returns a 7 element named tuple instead of a 4 element one.

This means that hybrid 2/3 code needs to consistently use name based item access rather than tuple unpacking, but other than that, all code related to the first four fields can be identical across versions. (Code related to handling the extra three fields will naturally only be needed on 3.x)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27172>
_______________________________________

From report at bugs.python.org  Tue Oct 10 03:03:55 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 07:03:55 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507619035.75.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think if someone is going to be put off by a FutureWarning, then that indicates they're not yet familiar with just what the provisional API status means, and those are exactly the folks we *want* to scare away from provisional APIs (or features in third party libraries and frameworks that depend on them).

After all, if "Set 'use_provisional_<module> = True' in __main__" is more of an inconvenience than someone is prepared to tolerate to enable warning-free access to a still evolving feature, imagine how upset they'd be if we actually *did* make a breaking change to that API.

I did realise my draft warning was missing a bit though, which was to explain how to turn it off:

    import __main__
    _feature_flag = f"use_provisional_{__name__}"
    if not getattr(__main__, _feature_flag):
        import warnings
        _provisional_msg = f"The {__name__} module is currently a provisional API - see documentation for details. Set '__main__.{_feature_flag} = True' to disable this warning."
        warnings.warn(FutureWarning, _provisional_msg)

I also revised the draft message to account for Guido's observation about even "provisional" APIs being mostly stable by directing folks to the module documentation for details. That way the maintainers of the provisional API don't need to duplicate their explanation of how provisional the module actually is (e.g. the typing docs make it clear that feature additions and API changes are currently in scope for maintenance releases, but outright removal isn't listed as a possible outcome).

Folks that want to always opt-in to various features in their REPL sessions can then set them via PYTHONSTARTUP.

I'll also note here why I'm proposing this as a per-process flag rather than a per-module one:

- checking a feature flag in __main__ is easy, checking a flag in the "importing module" is hard
- module caching means only the first import would actually run the code to emit the warning any way
- we know from experience that having to set per-module __future__ flags to access backwards incompatible syntax changes genuinely *is* annoying (to the point where we'll implement clever tricks like those Yury came up with for native coroutines to avoid needing them)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 03:45:07 2017
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Oct 2017 07:45:07 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507621507.56.0.213398074469.issue31741@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

The "backports" module you refer to as being in site-packages is not shipped with the standard library, it's a 3rd party addon that presumably you installed yourself. You'll need to let us know what you did to install it.

You say you manipulate sys.path manually in your code. Please provide:

1. the value of sys.path before you change it.
2. The value of sys.modules.get('backports') before you change sys.path.
3. the value of sys.path after you change it.
4. The value of sys.modules.get('backports') after you change sys.path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 04:46:31 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Tue, 10 Oct 2017 08:46:31 +0000
Subject: [issue31735] Documentation incorrectly states how descriptors are
 invoked
In-Reply-To: <1507561484.86.0.213398074469.issue31735@psf.upfronthosting.co.za>
Message-ID: <1507625191.24.0.213398074469.issue31735@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

"We know this doesn't happen because nothing is printed to stdout."

Try running Obj().d, you will get output.

Obj.d does not work because it is on a *class*, and so it runs, per the docs:

'Obj.__dict__['d'].__get__(None, Obj)'

whereas you consider running it on an instance to get:

b = Obj()
b.d
# equivalent to
type(b).__dict__['d'].__get__(b, type(b))

and you will get output twice.

[Note, on python2 you will get an error, I think this is because your class does not inherit from object.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31735>
_______________________________________

From report at bugs.python.org  Tue Oct 10 04:59:44 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Tue, 10 Oct 2017 08:59:44 +0000
Subject: [issue31735] Documentation incorrectly states how descriptors are
 invoked
In-Reply-To: <1507561484.86.0.213398074469.issue31735@psf.upfronthosting.co.za>
Message-ID: <1507625984.66.0.213398074469.issue31735@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

I do think though that

"If d defines the method __get__(), then d.__get__(obj) is invoked according to the precedence rules listed below."

seems to contain a mistake in that it should have

d.__get__(obj, type(obj)) instead of d.__get__(obj)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31735>
_______________________________________

From report at bugs.python.org  Tue Oct 10 05:51:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 09:51:55 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507629115.2.0.213398074469.issue31415@psf.upfronthosting.co.za>


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


New changeset a997c7b434631f51e00191acea2ba6097691e859 by Victor Stinner in branch 'master':
bpo-31415: Add _PyTime_GetPerfCounter() and use it for -X importtime (#3936)
https://github.com/python/cpython/commit/a997c7b434631f51e00191acea2ba6097691e859


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct 10 07:00:17 2017
From: report at bugs.python.org (=?utf-8?q?Ante_Peri=C4=87?=)
Date: Tue, 10 Oct 2017 11:00:17 +0000
Subject: [issue31743] Proportional Width Font on Generated Python Docs PDFs
Message-ID: <1507633217.5.0.213398074469.issue31743@psf.upfronthosting.co.za>


New submission from Ante Peri? <synthmeat at gmail.com>:

Fonts in the generated documentation PDFs, for all Python versions, are proportional width in code blocks, unlike in HTML version, where they are fixed-width.

Example https://docs.python.org/2.7/archives/python-2.7.14-docs-pdf-a4.zip

----------
assignee: docs at python
components: Documentation
files: Screenshot 2017-10-10 12.41.34.png
messages: 304024
nosy: docs at python, synthmeat
priority: normal
severity: normal
status: open
title: Proportional Width Font on Generated Python Docs PDFs
type: enhancement
versions: Python 2.7
Added file: https://bugs.python.org/file47203/Screenshot 2017-10-10 12.41.34.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31743>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:17:43 2017
From: report at bugs.python.org (Brian Sidebotham)
Date: Tue, 10 Oct 2017 12:17:43 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
Message-ID: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>


New submission from Brian Sidebotham <brian at wanless-systems.com>:

I am getting the following error when trying to compile Python 2.7.14 (and previous 2.7 versions) on CentOS and RHEL7.

The main problem is that CONFIG_ARGS does not exist. I've included the build. This RPATH is correct - it has to go through the RPM SPEC file so needs escaping like this to work.

Python 3.6.2 builds find like this, but Python 2.7 is failing to build. Have I missed something?

LDFLAGS='-Wl,-rpath=$\\$$ORIGIN/../lib' \
./configure --prefix=/opt/wsl \
            --enable-shared \
            --with-system-ffi \
            --with-ensurepip=yes \
            --enable-optimizations

...

ranlib libpython2.7.a
Modules/posixmodule.o: In function `posix_tmpnam':
/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/./Modules/posixmodule.c:7642: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
Modules/posixmodule.o: In function `posix_tempnam':
/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/./Modules/posixmodule.c:7589: warning: the use of `tempnam' is dangerous, better use `mkstemp'
gcc -pthread -Wl,-rpath=RIGIN/../lib -fprofile-generate  -Xlinker -export-dynamic -o python \
		Modules/python.o \
		-L. -lpython2.7 -lpthread -ldl  -lutil   -lm  
LD_LIBRARY_PATH=/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14 ./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
	echo "generate-posix-vars failed" ; \
	rm -f ./pybuilddir.txt ; \
	exit 1 ; \
fi
Traceback (most recent call last):
  File "./setup.py", line 33, in <module>
    COMPILED_WITH_PYDEBUG = ('--with-pydebug' in sysconfig.get_config_var("CONFIG_ARGS"))
TypeError: argument of type 'NoneType' is not iterable
make[2]: *** [sharedmods] Error 1
make[2]: Leaving directory `/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14'
make[1]: *** [build_all_generate_profile] Error 2
make[1]: Leaving directory `/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14'
make: *** [profile-opt] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.sFvDid (%build)





-bash-4.2# cd build/lib.linux-x86_64-2.7/
-bash-4.2# ls
_sysconfigdata.py  _sysconfigdata.pyc
-bash-4.2# cat _sysconfigdata.py
# system configuration generated and used by the sysconfig module
build_time_vars = {'AC_APPLE_UNIVERSAL_BUILD': 0,
 'AIX_GENUINE_CPLUSPLUS': 0,
 'AR': 'ar',
 'ARFLAGS': 'rc',
 'ATHEOS_THREADS': 0,
 'BASECFLAGS': '-fno-strict-aliasing',
 'BASEMODLIBS': '',
 'BEOS_THREADS': 0,
 'BINDIR': '/opt/wsl/bin',
 'BINLIBDEST': '/opt/wsl/lib/python2.7',
 'BLDLIBRARY': '-L. -lpython2.7',
 'BLDSHARED': 'gcc -pthread -shared -Wl,-rpath=RIGIN/../lib -fprofile-generate',
 'BUILDEXE': '',
 'BUILDPYTHON': 'python',
 'CC': 'gcc -pthread',
 'CCSHARED': '-fPIC',
 'CFLAGS': '-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes',
 'CFLAGSFORSHARED': '-fPIC',
 'CONFIGFILES': 'configure configure.ac acconfig.h pyconfig.h.in Makefile.pre.in',
 'CONFINCLUDEDIR': '/opt/wsl/include',
 'CONFINCLUDEPY': '/opt/wsl/include/python2.7',
 'COREPYTHONPATH': ':plat-linux2:lib-tk:lib-old',
 'COVERAGE_INFO': '/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/coverage.info',
 'COVERAGE_REPORT': '/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14/lcov-report',
 'COVERAGE_REPORT_OPTIONS': '--no-branch-coverage --title "CPython lcov report"',
 'CPPFLAGS': '-I. -IInclude -I./Include',
 'CXX': 'g++ -pthread',
 'C_THREADS': 0,
 'DESTDIRS': '/opt/wsl /opt/wsl/lib /opt/wsl/lib/python2.7 /opt/wsl/lib/python2.7/lib-dynload',
 'DESTLIB': '/opt/wsl/lib/python2.7',
 'DESTPATH': '',
 'DESTSHARED': '/opt/wsl/lib/python2.7/lib-dynload',
 'DIRMODE': 755,
 'DIST': 'README ChangeLog configure configure.ac acconfig.h pyconfig.h.in Makefile.pre.in Include Lib Misc Demo Ext-dummy',
 'DISTDIRS': 'Include Lib Misc Demo Ext-dummy',
 'DISTFILES': 'README ChangeLog configure configure.ac acconfig.h pyconfig.h.in Makefile.pre.in',
 'DLINCLDIR': '.',
 'DLLLIBRARY': '',
 'DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754': 0,
 'DOUBLE_IS_BIG_ENDIAN_IEEE754': 0,
 'DOUBLE_IS_LITTLE_ENDIAN_IEEE754': 1,
 'DYNLOADFILE': 'dynload_shlib.o',
 'ENABLE_IPV6': 1,
 'ENSUREPIP': 'upgrade',
 'EXE': '',
 'EXEMODE': 755,
 'EXTRAMACHDEPPATH': '',
 'EXTRAPLATDIR': '',
 'EXTRATESTOPTS': '',
 'EXTRA_CFLAGS': '',
 'FILEMODE': 644,
 'FLOCK_NEEDS_LIBBSD': 0,
 'GETPGRP_HAVE_ARG': 0,
 'GETTIMEOFDAY_NO_TZ': 0,
 'GITBRANCH': '',
 'GITTAG': '',
 'GITVERSION': '',
 'GLHACK': '-Dclear=__GLclear',
 'GNULD': 'yes',
 'HAVE_ACOSH': 1,
 'HAVE_ADDRINFO': 1,
 'HAVE_ALARM': 1,
 'HAVE_ALLOCA_H': 1,
 'HAVE_ALTZONE': 0,
 'HAVE_ASINH': 1,
 'HAVE_ASM_TYPES_H': 1,
 'HAVE_ATANH': 1,
 'HAVE_ATTRIBUTE_FORMAT_PARSETUPLE': 0,
 'HAVE_BIND_TEXTDOMAIN_CODESET': 1,
 'HAVE_BLUETOOTH_BLUETOOTH_H': 0,
 'HAVE_BLUETOOTH_H': 0,
 'HAVE_BROKEN_NICE': 0,
 'HAVE_BROKEN_PIPE_BUF': 0,
 'HAVE_BROKEN_POLL': 0,
 'HAVE_BROKEN_POSIX_SEMAPHORES': 0,
 'HAVE_BROKEN_PTHREAD_SIGMASK': 0,
 'HAVE_BROKEN_SEM_GETVALUE': 0,
 'HAVE_BROKEN_UNSETENV': 0,
 'HAVE_C99_BOOL': 1,
 'HAVE_CHFLAGS': 0,
 'HAVE_CHOWN': 1,
 'HAVE_CHROOT': 1,
 'HAVE_CLOCK': 1,
 'HAVE_COMPUTED_GOTOS': 1,
 'HAVE_CONFSTR': 1,
 'HAVE_CONIO_H': 0,
 'HAVE_COPYSIGN': 1,
 'HAVE_CTERMID': 1,
 'HAVE_CTERMID_R': 0,
 'HAVE_CURSES_H': 1,
 'HAVE_CURSES_IS_TERM_RESIZED': 1,
 'HAVE_CURSES_RESIZETERM': 1,
 'HAVE_CURSES_RESIZE_TERM': 1,
 'HAVE_DECL_ISFINITE': 1,
 'HAVE_DECL_ISINF': 1,
 'HAVE_DECL_ISNAN': 1,
 'HAVE_DECL_TZNAME': 0,
 'HAVE_DEVICE_MACROS': 1,
 'HAVE_DEV_PTC': 0,
 'HAVE_DEV_PTMX': 1,
 'HAVE_DIRECT_H': 0,
 'HAVE_DIRENT_H': 1,
 'HAVE_DLFCN_H': 1,
 'HAVE_DLOPEN': 1,
 'HAVE_DUP2': 1,
 'HAVE_DYNAMIC_LOADING': 1,
 'HAVE_EPOLL': 1,
 'HAVE_ERF': 1,
 'HAVE_ERFC': 1,
 'HAVE_ERRNO_H': 1,
 'HAVE_EXECV': 1,
 'HAVE_EXPM1': 1,
 'HAVE_FCHDIR': 1,
 'HAVE_FCHMOD': 1,
 'HAVE_FCHOWN': 1,
 'HAVE_FCNTL_H': 1,
 'HAVE_FDATASYNC': 1,
 'HAVE_FINITE': 1,
 'HAVE_FLOCK': 1,
 'HAVE_FORK': 1,
 'HAVE_FORKPTY': 1,
 'HAVE_FPATHCONF': 1,
 'HAVE_FSEEK64': 0,
 'HAVE_FSEEKO': 1,
 'HAVE_FSTATVFS': 1,
 'HAVE_FSYNC': 1,
 'HAVE_FTELL64': 0,
 'HAVE_FTELLO': 1,
 'HAVE_FTIME': 1,
 'HAVE_FTRUNCATE': 1,
 'HAVE_GAI_STRERROR': 1,
 'HAVE_GAMMA': 1,
 'HAVE_GCC_ASM_FOR_X87': 1,
 'HAVE_GETADDRINFO': 1,
 'HAVE_GETCWD': 1,
 'HAVE_GETC_UNLOCKED': 1,
 'HAVE_GETENTROPY': 0,
 'HAVE_GETGROUPS': 1,
 'HAVE_GETHOSTBYNAME': 0,
 'HAVE_GETHOSTBYNAME_R': 1,
 'HAVE_GETHOSTBYNAME_R_3_ARG': 0,
 'HAVE_GETHOSTBYNAME_R_5_ARG': 0,
 'HAVE_GETHOSTBYNAME_R_6_ARG': 1,
 'HAVE_GETITIMER': 1,
 'HAVE_GETLOADAVG': 1,
 'HAVE_GETLOGIN': 1,
 'HAVE_GETNAMEINFO': 1,
 'HAVE_GETPAGESIZE': 1,
 'HAVE_GETPEERNAME': 1,
 'HAVE_GETPGID': 1,
 'HAVE_GETPGRP': 1,
 'HAVE_GETPID': 1,
 'HAVE_GETPRIORITY': 1,
 'HAVE_GETPWENT': 1,
 'HAVE_GETRESGID': 1,
 'HAVE_GETRESUID': 1,
 'HAVE_GETSID': 1,
 'HAVE_GETSPENT': 1,
 'HAVE_GETSPNAM': 1,
 'HAVE_GETTIMEOFDAY': 1,
 'HAVE_GETWD': 1,
 'HAVE_GRP_H': 1,
 'HAVE_HSTRERROR': 1,
 'HAVE_HYPOT': 1,
 'HAVE_IEEEFP_H': 0,
 'HAVE_INET_ATON': 1,
 'HAVE_INET_PTON': 1,
 'HAVE_INITGROUPS': 1,
 'HAVE_INT32_T': 1,
 'HAVE_INT64_T': 1,
 'HAVE_INTTYPES_H': 1,
 'HAVE_IO_H': 0,
 'HAVE_KILL': 1,
 'HAVE_KILLPG': 1,
 'HAVE_KQUEUE': 0,
 'HAVE_LANGINFO_H': 1,
 'HAVE_LARGEFILE_SUPPORT': 0,
 'HAVE_LCHFLAGS': 0,
 'HAVE_LCHMOD': 0,
 'HAVE_LCHOWN': 1,
 'HAVE_LGAMMA': 1,
 'HAVE_LIBDL': 1,
 'HAVE_LIBDLD': 0,
 'HAVE_LIBIEEE': 0,
 'HAVE_LIBINTL_H': 1,
 'HAVE_LIBREADLINE': 1,
 'HAVE_LIBRESOLV': 0,
 'HAVE_LIBUTIL_H': 0,
 'HAVE_LINK': 1,
 'HAVE_LINUX_NETLINK_H': 1,
 'HAVE_LINUX_TIPC_H': 1,
 'HAVE_LOG1P': 1,
 'HAVE_LONG_DOUBLE': 1,
 'HAVE_LONG_LONG': 1,
 'HAVE_LSTAT': 1,
 'HAVE_MAKEDEV': 1,
 'HAVE_MEMMOVE': 1,
 'HAVE_MEMORY_H': 1,
 'HAVE_MKFIFO': 1,
 'HAVE_MKNOD': 1,
 'HAVE_MKTIME': 1,
 'HAVE_MMAP': 1,
 'HAVE_MREMAP': 1,
 'HAVE_NCURSES_H': 1,
 'HAVE_NDIR_H': 0,
 'HAVE_NETPACKET_PACKET_H': 1,
 'HAVE_NICE': 1,
 'HAVE_OPENPTY': 1,
 'HAVE_OSX105_SDK': 0,
 'HAVE_PATHCONF': 1,
 'HAVE_PAUSE': 1,
 'HAVE_PLOCK': 0,
 'HAVE_POLL': 1,
 'HAVE_POLL_H': 1,
 'HAVE_PROCESS_H': 0,
 'HAVE_PROTOTYPES': 1,
 'HAVE_PTH': 0,
 'HAVE_PTHREAD_ATFORK': 1,
 'HAVE_PTHREAD_DESTRUCTOR': 0,
 'HAVE_PTHREAD_H': 1,
 'HAVE_PTHREAD_INIT': 0,
 'HAVE_PTHREAD_SIGMASK': 1,
 'HAVE_PTY_H': 1,
 'HAVE_PUTENV': 1,
 'HAVE_READLINK': 1,
 'HAVE_REALPATH': 1,
 'HAVE_RL_CALLBACK': 1,
 'HAVE_RL_CATCH_SIGNAL': 1,
 'HAVE_RL_COMPLETION_APPEND_CHARACTER': 1,
 'HAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK': 1,
 'HAVE_RL_COMPLETION_MATCHES': 1,
 'HAVE_RL_COMPLETION_SUPPRESS_APPEND': 1,
 'HAVE_RL_PRE_INPUT_HOOK': 1,
 'HAVE_RL_RESIZE_TERMINAL': 1,
 'HAVE_ROUND': 1,
 'HAVE_SELECT': 1,
 'HAVE_SEM_GETVALUE': 1,
 'HAVE_SEM_OPEN': 1,
 'HAVE_SEM_TIMEDWAIT': 1,
 'HAVE_SEM_UNLINK': 1,
 'HAVE_SETEGID': 1,
 'HAVE_SETEUID': 1,
 'HAVE_SETGID': 1,
 'HAVE_SETGROUPS': 1,
 'HAVE_SETITIMER': 1,
 'HAVE_SETLOCALE': 1,
 'HAVE_SETPGID': 1,
 'HAVE_SETPGRP': 1,
 'HAVE_SETREGID': 1,
 'HAVE_SETRESGID': 1,
 'HAVE_SETRESUID': 1,
 'HAVE_SETREUID': 1,
 'HAVE_SETSID': 1,
 'HAVE_SETUID': 1,
 'HAVE_SETVBUF': 1,
 'HAVE_SHADOW_H': 1,
 'HAVE_SIGACTION': 1,
 'HAVE_SIGINTERRUPT': 1,
 'HAVE_SIGNAL_H': 1,
 'HAVE_SIGRELSE': 1,
 'HAVE_SNPRINTF': 1,
 'HAVE_SOCKADDR_SA_LEN': 0,
 'HAVE_SOCKADDR_STORAGE': 1,
 'HAVE_SOCKETPAIR': 1,
 'HAVE_SPAWN_H': 1,
 'HAVE_SSIZE_T': 1,
 'HAVE_STATVFS': 1,
 'HAVE_STAT_TV_NSEC': 1,
 'HAVE_STAT_TV_NSEC2': 0,
 'HAVE_STDARG_PROTOTYPES': 1,
 'HAVE_STDINT_H': 1,
 'HAVE_STDLIB_H': 1,
 'HAVE_STRDUP': 1,
 'HAVE_STRFTIME': 1,
 'HAVE_STRINGS_H': 1,
 'HAVE_STRING_H': 1,
 'HAVE_STROPTS_H': 0,
 'HAVE_STRUCT_STAT_ST_BIRTHTIME': 0,
 'HAVE_STRUCT_STAT_ST_BLKSIZE': 1,
 'HAVE_STRUCT_STAT_ST_BLOCKS': 1,
 'HAVE_STRUCT_STAT_ST_FLAGS': 0,
 'HAVE_STRUCT_STAT_ST_GEN': 0,
 'HAVE_STRUCT_STAT_ST_RDEV': 1,
 'HAVE_STRUCT_TM_TM_ZONE': 1,
 'HAVE_SYMLINK': 1,
 'HAVE_SYSCONF': 1,
 'HAVE_SYSEXITS_H': 1,
 'HAVE_SYS_AUDIOIO_H': 0,
 'HAVE_SYS_BSDTTY_H': 0,
 'HAVE_SYS_DIR_H': 0,
 'HAVE_SYS_EPOLL_H': 1,
 'HAVE_SYS_EVENT_H': 0,
 'HAVE_SYS_FILE_H': 1,
 'HAVE_SYS_LOADAVG_H': 0,
 'HAVE_SYS_LOCK_H': 0,
 'HAVE_SYS_MKDEV_H': 0,
 'HAVE_SYS_MODEM_H': 0,
 'HAVE_SYS_NDIR_H': 0,
 'HAVE_SYS_PARAM_H': 1,
 'HAVE_SYS_POLL_H': 1,
 'HAVE_SYS_RANDOM_H': 0,
 'HAVE_SYS_RESOURCE_H': 1,
 'HAVE_SYS_SELECT_H': 1,
 'HAVE_SYS_SOCKET_H': 1,
 'HAVE_SYS_STATVFS_H': 1,
 'HAVE_SYS_STAT_H': 1,
 'HAVE_SYS_TERMIO_H': 0,
 'HAVE_SYS_TIMES_H': 1,
 'HAVE_SYS_TIME_H': 1,
 'HAVE_SYS_TYPES_H': 1,
 'HAVE_SYS_UN_H': 1,
 'HAVE_SYS_UTSNAME_H': 1,
 'HAVE_SYS_WAIT_H': 1,
 'HAVE_TCGETPGRP': 1,
 'HAVE_TCSETPGRP': 1,
 'HAVE_TEMPNAM': 1,
 'HAVE_TERMIOS_H': 1,
 'HAVE_TERM_H': 1,
 'HAVE_TGAMMA': 1,
 'HAVE_THREAD_H': 0,
 'HAVE_TIMEGM': 1,
 'HAVE_TIMES': 1,
 'HAVE_TMPFILE': 1,
 'HAVE_TMPNAM': 1,
 'HAVE_TMPNAM_R': 1,
 'HAVE_TM_ZONE': 1,
 'HAVE_TRUNCATE': 1,
 'HAVE_TZNAME': 0,
 'HAVE_UCS4_TCL': 0,
 'HAVE_UINT32_T': 1,
 'HAVE_UINT64_T': 1,
 'HAVE_UINTPTR_T': 1,
 'HAVE_UNAME': 1,
 'HAVE_UNISTD_H': 1,
 'HAVE_UNSETENV': 1,
 'HAVE_USABLE_WCHAR_T': 0,
 'HAVE_UTIL_H': 0,
 'HAVE_UTIMES': 1,
 'HAVE_UTIME_H': 1,
 'HAVE_WAIT3': 1,
 'HAVE_WAIT4': 1,
 'HAVE_WAITPID': 1,
 'HAVE_WCHAR_H': 1,
 'HAVE_WCSCOLL': 1,
 'HAVE_WORKING_TZSET': 1,
 'HAVE_ZLIB_COPY': 1,
 'HAVE__GETPTY': 0,
 'HOST_GNU_TYPE': 'x86_64-pc-linux-gnu',
 'HURD_C_THREADS': 0,
 'INCLDIRSTOMAKE': '/opt/wsl/include /opt/wsl/include /opt/wsl/include/python2.7 /opt/wsl/include/python2.7',
 'INCLUDEDIR': '/opt/wsl/include',
 'INCLUDEPY': '/opt/wsl/include/python2.7',
 'INSTALL': '/usr/bin/install -c',
 'INSTALL_DATA': '/usr/bin/install -c -m 644',
 'INSTALL_PROGRAM': '/usr/bin/install -c',
 'INSTALL_SCRIPT': '/usr/bin/install -c',
 'INSTALL_SHARED': '/usr/bin/install -c -m 555',
 'INSTSONAME': 'libpython2.7.so.1.0',
 'LDCXXSHARED': 'g++ -pthread -shared',
 'LDLAST': '',
 'LDLIBRARY': 'libpython2.7.so',
 'LDLIBRARYDIR': '',
 'LDSHARED': 'gcc -pthread -shared -Wl,-rpath=RIGIN/../lib -fprofile-generate',
 'LIBC': '',
 'LIBDEST': '/opt/wsl/lib/python2.7',
 'LIBDIR': '/opt/wsl/lib',
 'LIBFFI_INCLUDEDIR': '',
 'LIBM': '-lm',
 'LIBOBJDIR': 'Python/',
 'LIBOBJS': '',
 'LIBP': '/opt/wsl/lib/python2.7',
 'LIBPC': '/opt/wsl/lib/pkgconfig',
 'LIBPL': '/opt/wsl/lib/python2.7/config',
 'LIBRARY': 'libpython2.7.a',
 'LIBRARY_OBJS': '\\',
 'LIBS': '-lpthread -ldl  -lutil',
 'LIBSUBDIRS': 'lib-tk lib-tk/test lib-tk/test/test_tkinter \\',
 'LINKCC': 'gcc -pthread',
 'LINKFORSHARED': '-Xlinker -export-dynamic',
 'LLVM_PROF_ERR': 'no',
 'LLVM_PROF_FILE': '',
 'LLVM_PROF_MERGER': 'true',
 'LN': 'ln',
 'LOCALMODLIBS': '',
 'MACHDEP': 'linux2',
 'MACHDEPPATH': ':plat-linux2',
 'MACHDEPS': 'plat-linux2',
 'MACHDEP_OBJS': '',
 'MACHDESTLIB': '/opt/wsl/lib/python2.7',
 'MACH_C_THREADS': 0,
 'MACOSX_DEPLOYMENT_TARGET': '',
 'MAINCC': 'gcc -pthread',
 'MAJOR_IN_MKDEV': 0,
 'MAJOR_IN_SYSMACROS': 0,
 'MAKESETUP': './Modules/makesetup',
 'MANDIR': '/opt/wsl/share/man',
 'MEMTESTOPTS': '-l -x test_subprocess test_io test_lib2to3 \\ -x test_dl test___all__ test_fork1 \\',
 'MKDIR_P': '/usr/bin/mkdir -p',
 'MODLIBS': '',
 'MODOBJS': 'Modules/threadmodule.o  Modules/signalmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/zipimport.o  Modules/symtablemodule.o  Modules/xxsubtype.o',
 'MODULE_OBJS': '\\',
 'MULTIARCH': '',
 'MVWDELCH_IS_EXPRESSION': 1,
 'OBJECT_OBJS': '\\',
 'OLDPATH': ':lib-old',
 'OPT': '-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes',
 'OTHER_LIBTOOL_OPT': '',
 'PACKAGE_BUGREPORT': 0,
 'PACKAGE_NAME': 0,
 'PACKAGE_STRING': 0,
 'PACKAGE_TARNAME': 0,
 'PACKAGE_URL': 0,
 'PACKAGE_VERSION': 0,
 'PARSER_HEADERS': '\\',
 'PARSER_OBJS': '\\ Parser/myreadline.o Parser/tokenizer.o',
 'PGEN': 'Parser/pgen',
 'PGENOBJS': '\\ \\',
 'PGENSRCS': '\\ \\',
 'PGOBJS': '\\',
 'PGO_PROF_GEN_FLAG': '-fprofile-generate',
 'PGO_PROF_USE_FLAG': '-fprofile-use -fprofile-correction',
 'PGSRCS': '\\',
 'PLATDIR': 'plat-linux2',
 'PLATMACDIRS': 'plat-mac plat-mac/Carbon plat-mac/lib-scriptpackages \\',
 'PLATMACPATH': ':plat-mac:plat-mac/lib-scriptpackages',
 'POBJS': '\\',
 'POSIX_SEMAPHORES_NOT_ENABLED': 0,
 'PROFILE_TASK': '-m test.regrtest --pgo -x test_asyncore test_gdb test_multiprocessing test_subprocess',
 'PSRCS': '\\',
 'PTHREAD_SYSTEM_SCHED_SUPPORTED': 1,
 'PURIFY': '',
 'PYLONG_BITS_IN_DIGIT': 0,
 'PYTHON': 'python',
 'PYTHONFRAMEWORK': '',
 'PYTHONFRAMEWORKDIR': 'no-framework',
 'PYTHONFRAMEWORKINSTALLDIR': '',
 'PYTHONFRAMEWORKPREFIX': '',
 'PYTHONPATH': ':plat-linux2:lib-tk:lib-old',
 'PYTHON_FOR_BUILD': './python -E',
 'PYTHON_FOR_REGEN': 'python2.7',
 'PYTHON_HEADERS': '\\',
 'PYTHON_OBJS': '\\',
 'PY_CFLAGS': '-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE',
 'PY_FORMAT_LONG_LONG': '"ll"',
 'PY_FORMAT_SIZE_T': '"z"',
 'PY_UNICODE_TYPE': 'unsigned short',
 'Py_DEBUG': 0,
 'Py_ENABLE_SHARED': 1,
 'Py_UNICODE_SIZE': 2,
 'Py_USING_UNICODE': 1,
 'QUICKTESTOPTS': '-l -x test_subprocess test_io test_lib2to3 \\',
 'RANLIB': 'ranlib',
 'RESSRCDIR': 'Mac/Resources/framework',
 'RETSIGTYPE': 'void',
 'RUNSHARED': 'LD_LIBRARY_PATH=/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14',
 'SCRIPTDIR': '/opt/wsl/lib',
 'SETPGRP_HAVE_ARG': 0,
 'SGI_ABI': '',
 'SHELL': '/bin/sh',
 'SHLIBS': '-lpthread -ldl  -lutil',
 'SHLIB_EXT': '".so"',
 'SIGNAL_OBJS': '',
 'SIGNED_RIGHT_SHIFT_ZERO_FILLS': 0,
 'SITEPATH': '',
 'SIZEOF_DOUBLE': 8,
 'SIZEOF_FLOAT': 4,
 'SIZEOF_FPOS_T': 16,
 'SIZEOF_INT': 4,
 'SIZEOF_LONG': 8,
 'SIZEOF_LONG_DOUBLE': 16,
 'SIZEOF_LONG_LONG': 8,
 'SIZEOF_OFF_T': 8,
 'SIZEOF_PID_T': 4,
 'SIZEOF_PTHREAD_T': 8,
 'SIZEOF_SHORT': 2,
 'SIZEOF_SIZE_T': 8,
 'SIZEOF_TIME_T': 8,
 'SIZEOF_UINTPTR_T': 8,
 'SIZEOF_VOID_P': 8,
 'SIZEOF_WCHAR_T': 4,
 'SIZEOF__BOOL': 1,
 'SO': '.so',
 'SRCDIRS': 'Parser Objects Python Modules',
 'SRC_GDB_HOOKS': './Tools/gdb/libpython.py',
 'STDC_HEADERS': 1,
 'STRICT_SYSV_CURSES': "/* Don't use ncurses extensions */",
 'STRINGLIB_HEADERS': '\\',
 'SUBDIRS': '',
 'SUBDIRSTOO': 'Include Lib Misc Demo',
 'SYSLIBS': '-lm',
 'SYS_SELECT_WITH_SYS_TIME': 1,
 'TANH_PRESERVES_ZERO_SIGN': 1,
 'TCLTK_INCLUDES': '',
 'TCLTK_LIBS': '',
 'TESTOPTS': '-l',
 'TESTPATH': '',
 'TESTPROG': './Lib/test/regrtest.py',
 'TESTPYTHON': 'LD_LIBRARY_PATH=/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14 ./python -Wd -3 -E -tt',
 'TESTPYTHONOPTS': '',
 'THREADOBJ': 'Python/thread.o',
 'TIME_WITH_SYS_TIME': 1,
 'TKPATH': ':lib-tk',
 'TM_IN_SYS_TIME': 0,
 'UNICODE_OBJS': 'Objects/unicodeobject.o Objects/unicodectype.o',
 'UNIVERSALSDK': '',
 'USE_COMPUTED_GOTOS': 0,
 'USE_TOOLBOX_OBJECT_GLUE': 0,
 'VA_LIST_IS_ARRAY': 1,
 'VERSION': '2.7',
 'WANT_SIGFPE_HANDLER': 0,
 'WANT_WCTYPE_FUNCTIONS': 0,
 'WINDOW_HAS_FLAGS': 1,
 'WITH_DOC_STRINGS': 1,
 'WITH_DYLD': 0,
 'WITH_LIBINTL': 0,
 'WITH_NEXT_FRAMEWORK': 0,
 'WITH_PYMALLOC': 1,
 'WITH_THREAD': 1,
 'WITH_TSC': 0,
 'WITH_VALGRIND': 0,
 'X87_DOUBLE_ROUNDING': 0,
 'XMLLIBSUBDIRS': 'xml xml/dom xml/etree xml/parsers xml/sax',
 'abs_builddir': '/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14',
 'abs_srcdir': '/opt/jenkins/workspace/Build_WSL_Python2_on_RHEL7/BUILD/Python-2.7.14',
 'build': 'x86_64-pc-linux-gnu',
 'datarootdir': '/opt/wsl/share',
 'exec_prefix': '/opt/wsl',
 'host': 'x86_64-pc-linux-gnu',
 'prefix': '/opt/wsl',
 'srcdir': '.'}

----------
components: Build
messages: 304025
nosy: Brian Sidebotham
priority: normal
severity: normal
status: open
title: Python 2.7.14 Fails to compile on CentOS/RHEL7
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:35:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 12:35:15 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507638915.64.0.213398074469.issue31415@psf.upfronthosting.co.za>


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


----------
pull_requests: +3914

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:40:14 2017
From: report at bugs.python.org (Mark Wright)
Date: Tue, 10 Oct 2017 12:40:14 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507639214.47.0.213398074469.issue30008@psf.upfronthosting.co.za>


Change by Mark Wright <gienah at gentoo.org>:


----------
pull_requests: +3915

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:41:05 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 10 Oct 2017 12:41:05 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <38f191ad-6d75-8461-d717-ea9822e2b164@egenix.com>


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

I'm not sure whether this is related, but your quoting for --rpath
doesn't appear to work:

On 10.10.2017 14:17, Brian Sidebotham wrote:
> LDFLAGS='-Wl,-rpath=$\\$$ORIGIN/../lib' \
> ...
> gcc -pthread -Wl,-rpath=RIGIN/../lib -fprofile-generate  -Xlinker -export-dynamic -o python \
> 		Modules/python.o \
> 		-L. -lpython2.7 -lpthread -ldl  -lutil   -lm  

The CONFIG_ARGS variable should always be set, so I assume that
your _sysconfigdata.py was generated in a previous broken build.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From mal at egenix.com  Tue Oct 10 08:40:59 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 10 Oct 2017 14:40:59 +0200
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
References: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <38f191ad-6d75-8461-d717-ea9822e2b164@egenix.com>

I'm not sure whether this is related, but your quoting for --rpath
doesn't appear to work:

On 10.10.2017 14:17, Brian Sidebotham wrote:
> LDFLAGS='-Wl,-rpath=$\\$$ORIGIN/../lib' \
> ...
> gcc -pthread -Wl,-rpath=RIGIN/../lib -fprofile-generate  -Xlinker -export-dynamic -o python \
> 		Modules/python.o \
> 		-L. -lpython2.7 -lpthread -ldl  -lutil   -lm  

The CONFIG_ARGS variable should always be set, so I assume that
your _sysconfigdata.py was generated in a previous broken build.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Tue Oct 10 08:46:27 2017
From: report at bugs.python.org (Mark Wright)
Date: Tue, 10 Oct 2017 12:46:27 +0000
Subject: [issue30008] OpenSSL 1.1.0 deprecated functions
In-Reply-To: <1491496485.65.0.239768530197.issue30008@psf.upfronthosting.co.za>
Message-ID: <1507639587.06.0.213398074469.issue30008@psf.upfronthosting.co.za>


Mark Wright <gienah at gentoo.org> added the comment:

Thanks, I opened
https://github.com/python/cpython/pull/3943
for the rest of the changes (on top of your changes in
https://github.com/python/cpython/pull/3934)
to allow it to compile with OpenSSL 1.1.0f compiled with
disable-deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30008>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:49:43 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Oct 2017 12:49:43 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507639783.03.0.213398074469.issue31742@psf.upfronthosting.co.za>


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

I think there needs to be an easy way to turn off the warnings while running tests, as well.  I don't want to be bothered by those messages when testing parts of my package that are consciously using the provisional features.

But really, I agree with Guido: if this were opt in, and set on by default in test harnesses like unittest, that would make sense to me.  Otherwise I think we'll be revisiting some of the pain that caused us to make deprecation warnings silent by default.

If you don't have tests for your code you should be expecting it to break eventually anyway :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:51:43 2017
From: report at bugs.python.org (Amber Brown)
Date: Tue, 10 Oct 2017 12:51:43 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507639903.79.0.213398074469.issue31742@psf.upfronthosting.co.za>


Amber Brown <hawkowl at atleastfornow.net> added the comment:

What is the point of an opt-in warning, when the entire point of the proposed warning is letting people know that they may be using something they are not fully educated or informed about the ramifications of using? If you know to turn on the warning, you know to check the list of provisional modules, or know that provisional modules exist in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 08:58:42 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Oct 2017 12:58:42 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507640322.23.0.213398074469.issue31742@psf.upfronthosting.co.za>


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

That's why I said set on by default by the test harnesses. The opt in would be done by the standard testing tools, not directly by the programmer.  That's how deprecation warnings work now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:02:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 13:02:41 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507640561.7.0.213398074469.issue31742@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I don't think that a special way for silencing FutureWarning is needed. You can use an existing mechanism.

    import warnings
    warnings.filterwarnings('ignore', '', FutureWarning, 'typing')

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:05:35 2017
From: report at bugs.python.org (Amber Brown)
Date: Tue, 10 Oct 2017 13:05:35 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507640735.38.0.213398074469.issue31742@psf.upfronthosting.co.za>


Amber Brown <hawkowl at atleastfornow.net> added the comment:

So you're proposing a coordinated effort across the half dozen, possibly more, test runners to enable some flags, so CPython doesn't log a single message, possibly two, that you're using unsupported experimental software with no backwards compatibility guarantee?

I think the warnings control setting there could be a good solution for your "I don't care, don't show the warning" use case, but I also think explicit disabling per module is a better solution to recommend to users (since we might know that we're using typing, and we say "we are okay with using typing", but might not realise that we're silencing a new provisional module used by an updated library sometime in the future).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:09:52 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 13:09:52 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507640992.54.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Deprecation warnings were different: we turned those off by default because currently working applications could start emitting console warnings simply because an end user ran them on a newer version of Python.

With future warnings, we're instead trying to detect cases where:

* a user has heard about a cool new Python standard library API, starts trying it out, but has no idea yet that it isn't covered by our regular backwards compatibility assurances. If they're a beginner or a corporation, this is setting them up for potential problems without any clear indication they might be doing something they may want to reconsider
* you upgraded a dependency and it started relying on a provisional API, and you'd prefer to stick with the old version rather than risking relying on the provisional interface

Neither of those situations can be encountered simply by running an existing *application* on a newer version of Python (assuming the application bundles all of its dependencies other than the runtime itself).

Neither of them is helped by an opt-in flag either, since the scenarios we're trying to detect include the affected user either:

1. Not knowing about provisional APIs at all;
2. Not knowing that *that particular* API is provisional; or
3. Not knowing that a dependency on that particular API has been introduced

Since the warning would be emitted through the regular warnings machinery, all those options would be available to turn it off, but there'd also be the even more convenient option of just setting "use_provisional_typing = True" in __main__ and leaving the warnings settings alone.

It's clear to me from both Guido's and David's confusion that this idea is going to need to go through the PEP process though, which is probably a reasonable thing to do anyway (since one of the outcomes would be an amendment to PEP 411 to include the programmatic warning mechanism).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:09:55 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Oct 2017 13:09:55 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507640995.66.0.213398074469.issue31742@psf.upfronthosting.co.za>


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

I imagine we could make it controlled by the same setting that controls deprecation warnings, with some way to differentiate them if you really need to.  I forget exactly how that warning control works, so maybe that would be awkward, but I wouldn't be surprised if it was relatively easy.  That way test runners would automatically be enabling the warning without having to do anything.  (If a test runner isn't already automatically enabling deprecation warnings, then I doubt it will want to automatically enable future warnings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:12:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 13:12:06 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507641126.0.0.213398074469.issue31705@psf.upfronthosting.co.za>


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

Charalampos Stratakis: "Attaching the strace output."

Oh thanks! I guess tha the interesting syscalls are:

socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3
bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
accept4(3, NULL, NULL, SOCK_CLOEXEC)    = 4
send(4, "abc", 3, 0)                    = -1 ENOKEY (Required key not available)
close(4)                                = 0

test_socket calls bind() with typ='hash', name='sha256', but in the strace, I only see 'hash'.

strace is maybe outdated and fails to display the full bind() address, or Python doesn't serialize correctly the address.

--

On my Fedora 26, I see sha256 in the bind call:

socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3
bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0sha256\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
accept4(3, NULL, NULL, SOCK_CLOEXEC)    = 4
sendto(4, "abc", 3, 0, NULL, 0)         = 3
recvfrom(4, "\272x\26\277\217\1\317\352AA@\336]\256\"#\260\3a\243\226\27z\234\264\20\377a\362\0\25\255", 512, 0, NULL, NULL) = 32
close(4)                                = 0
accept4(3, NULL, NULL, SOCK_CLOEXEC)    = 4
sendto(4, "a", 1, MSG_MORE, NULL, 0)    = 1
sendto(4, "b", 1, MSG_MORE, NULL, 0)    = 1
sendto(4, "c", 1, MSG_MORE, NULL, 0)    = 1
sendto(4, "", 0, 0, NULL, 0)            = 0
recvfrom(4, "\272x\26\277\217\1\317\352AA@\336]\256\"#\260\3a\243\226\27z\234\264\20\377a\362\0\25\255", 512, 0, NULL, NULL) = 32
close(4)                                = 0
close(3)                                = 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:13:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 13:13:34 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507641214.4.0.213398074469.issue31705@psf.upfronthosting.co.za>


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

> strace is maybe outdated and fails to display the full bind() address,

I vote for this option since I see addrlen=88 in both examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:14:48 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 13:14:48 +0000
Subject: [issue31719] [2.7] test_regrtest.test_crashed() fails on s390x
In-Reply-To: <1507322101.2.0.213398074469.issue31719@psf.upfronthosting.co.za>
Message-ID: <1507641288.64.0.213398074469.issue31719@psf.upfronthosting.co.za>


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

> Why not use just abort() or Py_FatalError()?

I try to test how a real program crash, like a real invalid memory read. Maybe it doesn't matter much here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31719>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:18:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 13:18:16 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1507641496.86.0.213398074469.issue26546@psf.upfronthosting.co.za>


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

Since you closed the issue, Julien, I changed the status of the PEP 545 to Final:
https://github.com/python/peps/commit/14092e51dea5c5c6391458da4a2ad92adad227b9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:19:38 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Oct 2017 13:19:38 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507641578.95.0.213398074469.issue31742@psf.upfronthosting.co.za>


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

Nick says: "Neither of those situations can be encountered simply by running an existing *application* on a newer version of Python". 

I fail to see the operational difference between running an application on a newer version of Python and doing a pip --upgrade or yum update and then running the application.  So that argument boils down to "this warning should be on by default", which is what we are discussing :)

I'm happy to leave this to the PEP process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:20:44 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 13:20:44 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507641644.08.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A note regarding *only* using the warnings module to turn things off:

The problem I have with that is that the UX is relatively clumsy, and hence runs into the concern Guido mentions above: "having this warning pop up every time you import a provisional module while developing code feels like harassment of the very users we'd like to try out the provisional APIs."

By contrast, "To rely on this provisional feature without getting a runtime FutureWarning, set this application level feature flag in your __main__ module" feels like exactly the right level of affirmative agreement to me - the equivalent of clicking through a confirmation dialog, or ticking an "I agree" check box on a form.

Libraries registering that agreement on behalf of their users would then always be inappropriate, while whether or not it was appropriate for a framework to do it would depend on the framework and the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:25:56 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Oct 2017 13:25:56 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507641956.07.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The deprecation warnings weren't turned off due to Python developers running things in virtual environments - they were turned off due to Linux distros upgrading their system Python runtimes, and Linux ISVs getting an influx of new bug reports from their users.

So the cases of relevance were ones where all the app dependencies were bundled *except* the runtime itself.

By contrast, one of the things we *want* to warn about in this case is folks acquiring transitive dependencies on provisional APIs that they may not want to depend on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:38:35 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 10 Oct 2017 13:38:35 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <1507642715.82.0.213398074469.issue31744@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Which CentOS/RHEL version do you have?

Could you provide the output of 'cat /etc/redhat-release' ?

----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Tue Oct 10 09:45:40 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 10 Oct 2017 13:45:40 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507643140.65.0.213398074469.issue31705@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Indeed the version of strace is 'strace-4.12-4.el7'.

I will try to provide output from the latest one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:08:15 2017
From: report at bugs.python.org (Kay Hayen)
Date: Tue, 10 Oct 2017 14:08:15 +0000
Subject: [issue31745] Overloading "Py_GetPath" does not work
Message-ID: <1507644495.71.0.213398074469.issue31745@psf.upfronthosting.co.za>


New submission from Kay Hayen <kay.hayen at gmail.com>:

Hello,

for my Python compiler Nuitka, I want to make sure that compiled binaries in standalone mode do not access the original installation, but solely the distribution folder created.

I am using the new API Py_SetPath on Python3 and it works fine. The Python2.7 documentation of the C-API however says: 

The embedding application can steer the search by calling Py_SetProgramName(file) before calling Py_Initialize(). Note that PYTHONHOME still overrides this and PYTHONPATH is still inserted in front of the standard path. An application that requires total control has to provide its own implementation of Py_GetPath(), Py_GetPrefix(), Py_GetExecPrefix(), and Py_GetProgramFullPath() (all defined in Modules/getpath.c).

My attempts at overloading this have badly failed, because of conflicting "declspec" (dllimport vs dllexport). And when defining Py_GetPath away before making the include, so the conflict is not seen by the MSVC compiler, the result is that the function is not called. 
Is this known to work? Can you point me to a working example, because my searches didn't reveal anything. Not normal web search, nor global code search for Py_GetPath code.

I did not try on Linux yet. I am assuming it might work, I just wanted to tap on knowledge on your side. Is it feasible. For Linux? For Windows?

Thanks,
Kay Hayen

----------
components: Build
messages: 304045
nosy: kayhayen
priority: normal
severity: normal
status: open
title: Overloading "Py_GetPath" does not work
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31745>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:10:49 2017
From: report at bugs.python.org (Iryna Shcherbina)
Date: Tue, 10 Oct 2017 14:10:49 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <1507644649.83.0.213398074469.issue31744@psf.upfronthosting.co.za>


Change by Iryna Shcherbina <shcherbina.iryna at gmail.com>:


----------
nosy: +ishcherb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:12:50 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Oct 2017 14:12:50 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <1507644770.53.0.213398074469.issue31744@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Do you already have an existing version of Python 2.7 installed at the prefix location /opt/ws1?  Because you are attempting to build with --enable-shared, the build may be picking up the already installed shared library.  Try building without --enable-shared or with a unique prefix location and see if it works then.

----------
nosy: +ned.deily -ishcherb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:15:40 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Oct 2017 14:15:40 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <1507644940.98.0.213398074469.issue31744@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ishcherb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:19:07 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 10 Oct 2017 14:19:07 +0000
Subject: [issue31740] refleaks when calling sqlite3.Connection.__init__() more
 than once
In-Reply-To: <1507581137.79.0.213398074469.issue31740@psf.upfronthosting.co.za>
Message-ID: <1507645147.13.0.213398074469.issue31740@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3917
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31740>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:31:19 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 10 Oct 2017 14:31:19 +0000
Subject: [issue31746] crashes in sqlite3.Connection in case it is
 uninitialized or partially initialized
Message-ID: <1507645879.63.0.213398074469.issue31746@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes a crash:
import sqlite3
connection = sqlite3.Connection.__new__(sqlite3.Connection)
connection.isolation_level

This is because pysqlite_connection_get_isolation_level() doesn't check whether
the Connection object is initialized.
pysqlite_connection_close() also doesn't check that, so we would get a crash
also if we replaced `connection.isolation_level` with `connection.close()`.

pysqlite_connection_set_isolation_level() doesn't crash in case of an
uninitialized Connection object, but it also doesn't raise an error, and IMHO
it should.


The following code causes a crash, too:
import sqlite3
try:
    connection = sqlite3.Connection.__new__(sqlite3.Connection)
    connection.__init__('', isolation_level='invalid isolation level')
except ValueError:
    pass

connection.cursor()

This is because `self->initialized` is set to 1 in the beginning of
pysqlite_connection_init(), so after it fails, we are left with a partially
initialized Connection object whose `self->initialized` is 1. Thus,
pysqlite_connection_cursor() thinks that the Connection object is initialized.
Eventually pysqlite_connection_register_cursor() is called, and it crashes
while trying to append to `connection->cursors`, which is NULL.

----------
components: Extension Modules
messages: 304047
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crashes in sqlite3.Connection in case it is uninitialized or partially initialized
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31746>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:39:39 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 10 Oct 2017 14:39:39 +0000
Subject: [issue31740] refleaks when calling sqlite3.Connection.__init__() more
 than once
In-Reply-To: <1507581137.79.0.213398074469.issue31740@psf.upfronthosting.co.za>
Message-ID: <1507646379.78.0.213398074469.issue31740@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

(opened bpo-31746 for the crashes i mentioned)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31740>
_______________________________________

From report at bugs.python.org  Tue Oct 10 10:45:38 2017
From: report at bugs.python.org (Andrew Clegg)
Date: Tue, 10 Oct 2017 14:45:38 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1507646738.24.0.213398074469.issue6135@psf.upfronthosting.co.za>


Andrew Clegg <andrew.clegg at durham.ac.uk> added the comment:

The commit for this bug (720f0cf580e2) introduces encoding and errors arguments but doesn't actually document what the values of these should be. In the case of the encoding it could be reasonably guessed, but the only way to determine what the value of 'errors' should be is to make the logical leap and look at the TextIOWrapper doc page.

And in reply to message #274510, there certainly should be a 'text=True' argument added. There are countless use cases where text rather than bytes is the expected behaviour, and currently this has to be triggered by using a more obscure option. In any case, it could be argued that text should be returned when shell=True since this mimics the behaviour of any shell program. 

(Sorry if adding a comment to a closed bug is poor etiquette; it seemed like the best place to put this comment)

----------
nosy: +andrewclegg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:02:04 2017
From: report at bugs.python.org (Denis Osipov)
Date: Tue, 10 Oct 2017 15:02:04 +0000
Subject: [issue31747] fatal error LNK1120 in PCbuild\python3dll.vcxproj
Message-ID: <1507647724.94.0.213398074469.issue31747@psf.upfronthosting.co.za>


New submission from Denis Osipov <osipov_d at list.ru>:

Since today (2017-10-10) I have compile error on Windows 10:

$ PCbuild/build.bat -e -d -p x64
Using py -3.6 (found with py.exe)
Fetching external libraries...
bzip2-1.0.6 already exists, skipping.
sqlite-3.14.2.0 already exists, skipping.
xz-5.2.2 already exists, skipping.
zlib-1.2.11 already exists, skipping.
Fetching external binaries...
openssl-bin-1.1.0f already exists, skipping.
tcltk-8.6.6.0 already exists, skipping.
Finished.
Using "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\\MSBuild\15.0\Bin\msbuild.exe" (found in the Visual Studio 2017 registry)

D:\repos\cpython>"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\\MSBuild\15.0\Bin\msbuild.exe" "D:\repos\cpython\PCbuild\pcbuild.proj" /t:Build /m /nologo /v:m /p:Configuration=Debug /p:Platform=x64 /p:IncludeExternals=true /p:IncludeSSL=true /p:IncludeTkinter=true /p:UseTestMarker= /p:GIT="C:\Program Files\Git\mingw64\bin\git.exe"
  Killing any running python_d.exe instances...
  Getting build info from "C:\Program Files\Git\mingw64\bin\git.exe"
  Building heads/master:a997c7b434 master
  pythoncore.vcxproj -> D:\repos\cpython\PCbuild\amd64\python37_d.dll
  pythoncore.vcxproj -> D:\repos\cpython\PCbuild\amd64\python37_d.pdb (Full PDB)
  _ctypes_test.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_test_d.pyd
  _ctypes_test.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_test_d.pdb (Full PDB)
  _testbuffer.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testbuffer_d.pyd
  _testbuffer.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testbuffer_d.pdb (Full PDB)
  _testcapi.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testcapi_d.pyd
  _testcapi.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testcapi_d.pdb (Full PDB)
  _testembed.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testembed_d.exe
  _testembed.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testembed_d.pdb (Full PDB)
  _testimportmultiple.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testimportmultiple_d.pyd
  _testimportmultiple.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testimportmultiple_d.pdb (Full PDB)
  _testmultiphase.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testmultiphase_d.pyd
  _testmultiphase.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testmultiphase_d.pdb (Full PDB)
  _testconsole.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testconsole_d.pyd
  _testconsole.vcxproj -> D:\repos\cpython\PCbuild\amd64\_testconsole_d.pdb (Full PDB)
  pylauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\py_d.exe
  pylauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\py_d.pdb (Full PDB)
  pywlauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyw_d.exe
  pywlauncher.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyw_d.pdb (Full PDB)
  pyshellext.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyshellext_d.dll
  pyshellext.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyshellext_d.pdb (Full PDB)
     ????????? ?????????? D:\repos\cpython\PCbuild\amd64\python3_dstub.lib ? ?????? D:\repos\cpython\PCbuild\amd64\python3_dstub.exp
  _asyncio.vcxproj -> D:\repos\cpython\PCbuild\amd64\_asyncio_d.pyd
  _asyncio.vcxproj -> D:\repos\cpython\PCbuild\amd64\_asyncio_d.pdb (Full PDB)
  _ctypes.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_d.pyd
  _ctypes.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ctypes_d.pdb (Full PDB)
  _decimal.vcxproj -> D:\repos\cpython\PCbuild\amd64\_decimal_d.pyd
  _decimal.vcxproj -> D:\repos\cpython\PCbuild\amd64\_decimal_d.pdb (Full PDB)
  LINK : ?? ?????? ??? ?? ????????? ?????? D:\repos\cpython\PCbuild\amd64\python3_d.dll ??? ????????? ???????????? ??????????; ??????????? ?????? ??????????
  _elementtree.vcxproj -> D:\repos\cpython\PCbuild\amd64\_elementtree_d.pyd
  _elementtree.vcxproj -> D:\repos\cpython\PCbuild\amd64\_elementtree_d.pdb (Full PDB)
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_alloc" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_create" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_delete" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_free" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_get" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_is_created" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
python3_d.def : error LNK2001: ????????????? ??????? ?????? "PyThread_tss_set" [D:\repos\cpython\PCbuild\python3dll.vcxproj]
D:\repos\cpython\PCbuild\amd64\python3_d.lib : fatal error LNK1120: ????????????? ??????? ?????????: 7 [D:\repos\cpython\PCbuild\python3dll.vcxproj]
  _multiprocessing.vcxproj -> D:\repos\cpython\PCbuild\amd64\_multiprocessing_d.pyd
  _multiprocessing.vcxproj -> D:\repos\cpython\PCbuild\amd64\_multiprocessing_d.pdb (Full PDB)
  _msi.vcxproj -> D:\repos\cpython\PCbuild\amd64\_msi_d.pyd
  _msi.vcxproj -> D:\repos\cpython\PCbuild\amd64\_msi_d.pdb (Full PDB)
  pyexpat.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyexpat_d.pyd
  pyexpat.vcxproj -> D:\repos\cpython\PCbuild\amd64\pyexpat_d.pdb (Full PDB)
  select.vcxproj -> D:\repos\cpython\PCbuild\amd64\select_d.pyd
  select.vcxproj -> D:\repos\cpython\PCbuild\amd64\select_d.pdb (Full PDB)
  unicodedata.vcxproj -> D:\repos\cpython\PCbuild\amd64\unicodedata_d.pyd
  unicodedata.vcxproj -> D:\repos\cpython\PCbuild\amd64\unicodedata_d.pdb (Full PDB)
  winsound.vcxproj -> D:\repos\cpython\PCbuild\amd64\winsound_d.pyd
  winsound.vcxproj -> D:\repos\cpython\PCbuild\amd64\winsound_d.pdb (Full PDB)
  _bz2.vcxproj -> D:\repos\cpython\PCbuild\amd64\_bz2_d.pyd
  _bz2.vcxproj -> D:\repos\cpython\PCbuild\amd64\_bz2_d.pdb (Full PDB)
  _overlapped.vcxproj -> D:\repos\cpython\PCbuild\amd64\_overlapped_d.pyd
  _overlapped.vcxproj -> D:\repos\cpython\PCbuild\amd64\_overlapped_d.pdb (Full PDB)
  liblzma.vcxproj -> D:\repos\cpython\PCbuild\amd64\liblzma_d.lib
  sqlite3.vcxproj -> D:\repos\cpython\PCbuild\amd64\sqlite3_d.dll
  sqlite3.vcxproj -> D:\repos\cpython\PCbuild\amd64\sqlite3_d.pdb (Full PDB)
  _socket.vcxproj -> D:\repos\cpython\PCbuild\amd64\_socket_d.pyd
  _socket.vcxproj -> D:\repos\cpython\PCbuild\amd64\_socket_d.pdb (Full PDB)
  _hashlib.vcxproj -> D:\repos\cpython\PCbuild\amd64\_hashlib_d.pyd
  _hashlib.vcxproj -> D:\repos\cpython\PCbuild\amd64\_hashlib_d.pdb (Full PDB)
  _sqlite3.vcxproj -> D:\repos\cpython\PCbuild\amd64\_sqlite3_d.pyd
  _sqlite3.vcxproj -> D:\repos\cpython\PCbuild\amd64\_sqlite3_d.pdb (Full PDB)
  _lzma.vcxproj -> D:\repos\cpython\PCbuild\amd64\_lzma_d.pyd
  _lzma.vcxproj -> D:\repos\cpython\PCbuild\amd64\_lzma_d.pdb (Full PDB)
  _ssl.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ssl_d.pyd
  _ssl.vcxproj -> D:\repos\cpython\PCbuild\amd64\_ssl_d.pdb (Full PDB)
  _tkinter.vcxproj -> D:\repos\cpython\PCbuild\amd64\_tkinter_d.pyd
  _tkinter.vcxproj -> D:\repos\cpython\PCbuild\amd64\_tkinter_d.pdb (Full PDB)

----------
components: Build
messages: 304050
nosy: denis-osipov
priority: normal
severity: normal
status: open
title: fatal error LNK1120 in PCbuild\python3dll.vcxproj
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31747>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:08:41 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 10 Oct 2017 15:08:41 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507648121.22.0.213398074469.issue31705@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Attaching the output of:

strace -s 128 -e trace=%network -o trace ./python3 -m test -v test_socket -m test_sha256

using the latest version of strace (4.19).

----------
Added file: https://bugs.python.org/file47204/trace2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:25:28 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 10 Oct 2017 15:25:28 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507316681.54.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <49489D98-D6D3-4096-96AF-F6A0234CD329@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Oct 6, 2017, at 15:04, Serhiy Storchaka <report at bugs.python.org> wrote:
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
> 
> Another solution (works in 3.6 too): set idpattern to r'(?-i:[_a-zA-Z][_a-zA-Z0-9]*)'.
> 
> This looks pretty weird, setting the re.IGNORECASE flag and then unsetting it. But it works, and don't break the user code that changes idpattern without changing flags.

Oh, I think I like that :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:25:52 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 10 Oct 2017 15:25:52 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507649152.33.0.213398074469.issue31672@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

With some comments to clarify of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:46:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 15:46:03 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1504175392.51.0.871887341171.issue31314@psf.upfronthosting.co.za>
Message-ID: <1507650363.61.0.213398074469.issue31314@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 3938 fixes this issue, but I'm wondering why self._split() returns an empty list only for long header names.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:48:16 2017
From: report at bugs.python.org (Devin Bayer)
Date: Tue, 10 Oct 2017 15:48:16 +0000
Subject: [issue14369] make __closure__ writable
In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za>
Message-ID: <1507650496.02.0.213398074469.issue14369@psf.upfronthosting.co.za>


Change by Devin Bayer <dev at doubly.so>:


----------
nosy: +akvadrako

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14369>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:48:43 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Oct 2017 15:48:43 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507650523.63.0.213398074469.issue31742@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I have no bandwidth for this discussion, but so far I am not convinced. What happened to "consenting adults"?

> [...] the entire point of the proposed warning letting people know that they may be using something they are not fully educated or informed about the ramifications of using

That describes most of the Python experience. :-)

I think you all should lighten up. It really sounds like a classic case of someone who was bitten badly by some obscure aspect of an API and then overreacts.

If the warning in the docs does not grab enough attention, change the text or formatting of that warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 11:50:04 2017
From: report at bugs.python.org (Devin Bayer)
Date: Tue, 10 Oct 2017 15:50:04 +0000
Subject: [issue14369] make __closure__ writable
In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za>
Message-ID: <1507650604.46.0.213398074469.issue14369@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

Any updates on this? I'm trying to implement hot module reloading using code from IPython, which tries to modify __closure__ in place. It fails silently and doesn't work, but indeed would be nice to have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14369>
_______________________________________

From report at bugs.python.org  Tue Oct 10 12:12:35 2017
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 10 Oct 2017 16:12:35 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507651955.34.0.213398074469.issue31742@psf.upfronthosting.co.za>


Donald Stufft <donald at stufft.io> added the comment:

> What happened to "consenting adults"?

Making sure they're actually consenting when getting into something that might potentially bite them in the ass seems like a sane and thoughtful thing to do to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 12:21:18 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 10 Oct 2017 16:21:18 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1507652478.96.0.213398074469.issue31733@psf.upfronthosting.co.za>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Tue Oct 10 12:33:34 2017
From: report at bugs.python.org (Carvell Scott)
Date: Tue, 10 Oct 2017 16:33:34 +0000
Subject: [issue1927] Change input() to always prompt to stderr
In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za>
Message-ID: <1507653214.38.0.213398074469.issue1927@psf.upfronthosting.co.za>


Change by Carvell Scott <carvell.scott at gmail.com>:


----------
nosy: +Carvell Scott

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1927>
_______________________________________

From report at bugs.python.org  Tue Oct 10 13:00:05 2017
From: report at bugs.python.org (Denis Osipov)
Date: Tue, 10 Oct 2017 17:00:05 +0000
Subject: [issue31747] fatal error LNK1120 in PCbuild\python3dll.vcxproj
In-Reply-To: <1507647724.94.0.213398074469.issue31747@psf.upfronthosting.co.za>
Message-ID: <1507654805.41.0.213398074469.issue31747@psf.upfronthosting.co.za>


Denis Osipov <osipov_d at list.ru> added the comment:

Oops... I've tried to rebuild, it didn't help. But after deleting folder cpython\PCbuild\amd64 everything works well again.

Sorry for false alarm.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31747>
_______________________________________

From report at bugs.python.org  Tue Oct 10 13:05:50 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Tue, 10 Oct 2017 17:05:50 +0000
Subject: [issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and
 posix_fildes_fd
Message-ID: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

These are needed only sometimes.

diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -1466,6 +1466,7 @@ path_error2(path_t *path, path_t *path2)
 
 /* POSIX generic methods */
 
+#if defined(HAVE_FSYNC) || defined(HAVE_FDATASYNC) || defined(HAVE_FCHDIR)
 static int
 fildes_converter(PyObject *o, void *p)
 {
@@ -1495,6 +1496,7 @@ posix_fildes_fd(int fd, int (*func)(int))
         return (!async_err) ? posix_error() : NULL;
     Py_RETURN_NONE;
 }
+#endif
 
 
 #ifdef MS_WINDOWS

----------
components: Build
messages: 304059
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 13:06:38 2017
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Oct 2017 17:06:38 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1507655198.17.0.213398074469.issue6135@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> The commit for this bug (720f0cf580e2) introduces encoding and errors arguments but doesn't actually document what the values of these should be

Do you mean it doesn't document that they take the normal encoding/errors arguments that all the other functions that do character encoding take? Or they don't specify which encoding you should use? The latter is not feasible, and if you mean the former then feel free to open a new issue for documentation.

Having a single "text" parameter is essentially what we had before - a magic option that modifies your data without giving you any ability to do it correctly. This change brought Popen in line with all the other places where we translate OS-level bytes into Python str, and it's done it in exactly the same way.

Also see msg274562 where Nick withdraws his own suggestion of a "text" parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Tue Oct 10 13:10:53 2017
From: report at bugs.python.org (Rich)
Date: Tue, 10 Oct 2017 17:10:53 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
Message-ID: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>


New submission from Rich <miserlou+python2 at gmail.com>:

This problem is an _extremely_ common one, a problem that almost any Python project of a reasonable size will encounter.

Given a number of bytes, say 123901842, format this as '123.9MB'.

The reason I strongly think that this should be included in the standard library is that if you look for how to do this through a Google search, there are an incredible amount of different solutions on StackOverflow, blog posts, forum posts, and various different libraries which provide this functionality - with varying levels of functionality and safety. You can also find different implementations of solutions to this problem inside of pretty much every major Python project (Django, etc.). In fact, I don't think I can think of any other function that gets copy-pasted into a project's 'util.py' file more commonly.

I think this should functionality should be provided in the standard math package, with arguments which allow to specific SI/NIST formatting and the number of significant digits to display. Implementing this would strongly cut down on the amount of cargo-cult Python programming in the world.

I'm willing to implement this if there's a consensus that it should be included.

Thanks!,
Rich Jones

----------
messages: 304061
nosy: miserlou2
priority: normal
severity: normal
status: open
title: Request: Human readable byte amounts in the standard library
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Tue Oct 10 13:46:02 2017
From: report at bugs.python.org (Devin Bayer)
Date: Tue, 10 Oct 2017 17:46:02 +0000
Subject: [issue31750] expose PyCell_Type in types module
Message-ID: <1507657562.56.0.213398074469.issue31750@psf.upfronthosting.co.za>


New submission from Devin Bayer <dev at doubly.so>:

The type of PyCell_Type is not available in the types module or anywhere else. Since this type is exposed to users it seems like it's a rather odd omission.

Related issues:
- https://bugs.python.org/issue2408
- https://bugs.python.org/issue1605

----------
components: Library (Lib)
messages: 304062
nosy: akvadrako
priority: normal
severity: normal
status: open
title: expose PyCell_Type in types module
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31750>
_______________________________________

From report at bugs.python.org  Tue Oct 10 13:57:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 17:57:12 +0000
Subject: [issue31750] expose PyCell_Type in types module
In-Reply-To: <1507657562.56.0.213398074469.issue31750@psf.upfronthosting.co.za>
Message-ID: <1507658232.9.0.213398074469.issue31750@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

According to discussions in the issues referred by you, this omission is intentional. Do you have any new arguments for adding the cell type in the types module?

----------
nosy: +serhiy.storchaka
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31750>
_______________________________________

From report at bugs.python.org  Tue Oct 10 14:05:57 2017
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 10 Oct 2017 18:05:57 +0000
Subject: [issue13601] sys.stderr should be line-buffered when stderr is not a
 TTY
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1507658757.25.0.213398074469.issue13601@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

> Looking at http://pubs.opengroup.org/onlinepubs/9699919799/functions/stdin.html (which also covers stdout and stderr), it specifically says about stderr: "When opened, the standard error stream is not fully buffered;".

I was of the impression that this is defined in ISO C already. Unfortunately, I only have ISO C 99 at hand, but this clearly states in section 7.19.3 (Files), enumeration item 7:

> As initially opened,  the  standard  error  stream  is  not  fully  buffered;  the  standard  input  and  standard output streams are fully buffered if and only if the stream can be determined not to refer
to an interactive device.

I am quite sure this is just as as it was in the original ANSI C standard.

----------
nosy: +torsten

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Tue Oct 10 14:14:40 2017
From: report at bugs.python.org (Michael DePalatis)
Date: Tue, 10 Oct 2017 18:14:40 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507659280.24.0.213398074469.issue31749@psf.upfronthosting.co.za>


Michael DePalatis <mike at depalatis.net> added the comment:

This would be a useful feature, but I don't think it quite fits in the math package. It might make more sense to use this with string formatting, for example:

{:h}.format(filesize)

where I use h as the format specifier since it doesn't appear to be taken yet and would be in line with "human-readable" options in tools like ls.

----------
nosy: +mivade

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Tue Oct 10 14:33:30 2017
From: report at bugs.python.org (Liel Fridman)
Date: Tue, 10 Oct 2017 18:33:30 +0000
Subject: [issue31738] Lib/site.py: method `abs_paths` is not documented
In-Reply-To: <1507581303.97.0.213398074469.issue31738@psf.upfronthosting.co.za>
Message-ID: <1507660410.9.0.213398074469.issue31738@psf.upfronthosting.co.za>


Liel Fridman <lielft at gmail.com> added the comment:

No, I've just tried to find something to work on as a first contribution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31738>
_______________________________________

From report at bugs.python.org  Tue Oct 10 14:47:22 2017
From: report at bugs.python.org (Devin Bayer)
Date: Tue, 10 Oct 2017 18:47:22 +0000
Subject: [issue31750] expose PyCell_Type in types module
In-Reply-To: <1507657562.56.0.213398074469.issue31750@psf.upfronthosting.co.za>
Message-ID: <1507661242.25.0.213398074469.issue31750@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

I have just reread those discussions and I don't see any reasoning behind omitting the cell type. It is barely mentioned.

Basically, I need this type and it isn't exposed anywhere. I don't care where it is, but the only way to get it right now is a hack, for example:

a = [1]
def f(): return a
return type(f.__closure__[0])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31750>
_______________________________________

From report at bugs.python.org  Tue Oct 10 14:51:16 2017
From: report at bugs.python.org (steven Michalske)
Date: Tue, 10 Oct 2017 18:51:16 +0000
Subject: [issue31751] Support for C++ 11 and/or C++ 14 in python.org installer
Message-ID: <1507661476.93.0.213398074469.issue31751@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

We are using some compiled cython modules with c++ 11 features.
This prohibits us from instructing users to install python from the python.org download.

Please consider using clang with support for C++ 11 and higher.
This would move the minimum OS X version away from 10.6 but as 10.6 is 8 years old and phased out 6 years ago it should be rare that non technical users would be using this OS version.

----------
components: Build, Installation, macOS
messages: 304068
nosy: hardkrash, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Support for C++ 11 and/or C++ 14 in python.org installer
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31751>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:03:58 2017
From: report at bugs.python.org (Oren Milman)
Date: Tue, 10 Oct 2017 19:03:58 +0000
Subject: [issue31722] _io.IncrementalNewlineDecoder doesn't inherit
 codecs.IncrementalDecoder
In-Reply-To: <1507386401.5.0.213398074469.issue31722@psf.upfronthosting.co.za>
Message-ID: <1507662238.29.0.213398074469.issue31722@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3918
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31722>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:05:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 19:05:39 +0000
Subject: [issue31722] _io.IncrementalNewlineDecoder doesn't inherit
 codecs.IncrementalDecoder
In-Reply-To: <1507386401.5.0.213398074469.issue31722@psf.upfronthosting.co.za>
Message-ID: <1507662339.85.0.213398074469.issue31722@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -3918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31722>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:22:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 19:22:16 +0000
Subject: [issue31750] expose PyCell_Type in types module
In-Reply-To: <1507657562.56.0.213398074469.issue31750@psf.upfronthosting.co.za>
Message-ID: <1507663336.12.0.213398074469.issue31750@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The reason is that nobody provided good enough arguments for exposing a cell type in the types module. The initial argument "types should expose all types used by the interpreter" was found to be bad. There are a lot of types (like "stderrprinter" or "list_reverseiterator") that shouldn't be exposed.

----------
nosy: +benjamin.peterson, gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31750>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:26:08 2017
From: report at bugs.python.org (Timothy Allen)
Date: Tue, 10 Oct 2017 19:26:08 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507663568.39.0.213398074469.issue31749@psf.upfronthosting.co.za>


Timothy Allen <tim at pyphilly.org> added the comment:

This would be a benefit to my team, for sure. I can't even tell you how many different solutions we currently use to make file sizes human readable - at least three.

----------
nosy: +FlipperPA

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:27:48 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 19:27:48 +0000
Subject: [issue31740] refleaks when calling sqlite3.Connection.__init__() more
 than once
In-Reply-To: <1507581137.79.0.213398074469.issue31740@psf.upfronthosting.co.za>
Message-ID: <1507663668.42.0.213398074469.issue31740@psf.upfronthosting.co.za>


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


New changeset 93c5a5df8ea118f6e4a153a7c8cccd65a5ff8bff by Victor Stinner (Oren Milman) in branch 'master':
bpo-31740: Prevent refleaks when sqlite3.Connection.__init__() is called more than once (GH-3944)
https://github.com/python/cpython/commit/93c5a5df8ea118f6e4a153a7c8cccd65a5ff8bff


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31740>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:35:17 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 19:35:17 +0000
Subject: [issue31740] refleaks when calling sqlite3.Connection.__init__() more
 than once
In-Reply-To: <1507581137.79.0.213398074469.issue31740@psf.upfronthosting.co.za>
Message-ID: <1507664117.4.0.213398074469.issue31740@psf.upfronthosting.co.za>


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

Oren Milman: thanks for your contribution! I merged your PR.

I don't consider that such corner case requires to backport the change to Python 2.7 and 3.6.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31740>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:38:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 19:38:38 +0000
Subject: [issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and
 posix_fildes_fd
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507664318.57.0.213398074469.issue31748@psf.upfronthosting.co.za>


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

Hi ????? ????????,

> These are needed only sometimes.

Would you mind to elaborate, please?

Which platform doesn't have os.fchdir(), os.fsync() nor os.fdatasync()?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:45:13 2017
From: report at bugs.python.org (Devin Bayer)
Date: Tue, 10 Oct 2017 19:45:13 +0000
Subject: [issue31750] expose PyCell_Type in types module
In-Reply-To: <1507657562.56.0.213398074469.issue31750@psf.upfronthosting.co.za>
Message-ID: <1507664713.05.0.213398074469.issue31750@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

Well that's true enough. My main argument is consistency. Cells and code objects together make up closures, so to manipulate closures you need both. Right now I am using a ctypes hack to modify the cells/closures, for what I consider a strategically important use-case. So I guess a type(cell) hack isn't out of place; the risk is it's fragile.

So, to really make hot reloading work with no hacks I need both this and the follow-up of https://bugs.python.org/issue14369 to be implemented. Or equivalently, a python interface to make closures mutable.

Honestly I don't know what your criteria are, so it's hard to make a point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31750>
_______________________________________

From report at bugs.python.org  Tue Oct 10 15:48:03 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Tue, 10 Oct 2017 19:48:03 +0000
Subject: [issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and
 posix_fildes_fd
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507664883.94.0.213398074469.issue31748@psf.upfronthosting.co.za>


????? ???????? <dilyan.palauzov at aegee.org> added the comment:

Having 'CFLAGS="-pipe -Werror -Wall -Wextra -O3 -fno-fat-lto-objects -flto" CXXFLAGS="-pipe -Wall -Wextra -O3 -fno-fat-lto-objects -flto" LDFLAGS="-Wl,-O1,-s -flto=12" ' in config.site and running "./configure" with gcc8 prints:

checking for fchdir... no
checking for fsync... no
checking for fdatasync... no

and config.log has:

configure:11440: checking for fchdir
configure:11453: gcc -c -pipe -Werror -Wall -Wextra -O3 -fno-fat-lto-objects -flto  conftest.c >&5
conftest.c: In function 'main':
conftest.c:250:7: error: unused variable 'x' [-Werror=unused-variable]
 void *x=fchdir
       ^
cc1: all warnings being treated as errors
configure:11453: $? = 1
configure: failed program was:
| /* confdefs.h */
...
| #define HAVE_DIRFD 1
| /* end confdefs.h.  */
| #include <unistd.h>
| int
| main ()
| {
| void *x=fchdir
|   ;
|   return 0;
| }
configure:11460: result: no

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 16:00:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 20:00:32 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507665632.4.0.213398074469.issue31749@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mean decimal or binary prefixes? 123901842 bytes can be formatted as "118.2 MiB". In different areas decimal and binary prefixes can be more common. For example the volume of hard disks usually is specified with decimal prefixes, but the volume of RAM -- with binary prefixes (32 GiB, not 34.4 GB). Sometimes even mixed prefixes can be used (1 MB = 1024000 bytes).

And when we talk about human-readability, we can't ignore localization. For many people "123,9 ??" looks more human-readable than "123.9 MB".

This is a complex problem and needs a complex solution. You can start from writing a special purposed package and adding it on PyPI. Maybe there are existing packages that solve this problem.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Tue Oct 10 16:05:13 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 20:05:13 +0000
Subject: [issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and
 posix_fildes_fd
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507665913.81.0.213398074469.issue31748@psf.upfronthosting.co.za>


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

Ok. My next question is: what is your operating system? What is your operating system version?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 16:10:36 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Oct 2017 20:10:36 +0000
Subject: [issue31750] expose PyCell_Type in types module
In-Reply-To: <1507657562.56.0.213398074469.issue31750@psf.upfronthosting.co.za>
Message-ID: <1507666236.85.0.213398074469.issue31750@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think the cell type is pretty fundamental to Python's semantic model. IIRC there once was a time when cells were entirely hidden from the user, but that's no longer true. Third-party code that uses them might want to have type annotations and then it's a pain when there's no way to talk about them. And no, that doesn't mean it belongs in typing.py -- that's not a scalable model, and in general we only want to shadow things there that must be generic (but aren't in types.py), like `List` or `re.Pattern`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31750>
_______________________________________

From report at bugs.python.org  Tue Oct 10 16:26:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 20:26:27 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507667187.95.0.213398074469.issue31728@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 39ecb9c71b6e55d8a61a710d0144231bd88f9ada by Serhiy Storchaka (Oren Milman) in branch 'master':
bpo-31728: Prevent crashes in _elementtree due to unsafe cleanup of Element.text and Element.tail (#3924)
https://github.com/python/cpython/commit/39ecb9c71b6e55d8a61a710d0144231bd88f9ada


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Tue Oct 10 16:31:37 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Tue, 10 Oct 2017 20:31:37 +0000
Subject: [issue31748] Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and
 posix_fildes_fd
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507667497.3.0.213398074469.issue31748@psf.upfronthosting.co.za>


????? ???????? <dilyan.palauzov at aegee.org> added the comment:

If I remove -Werror from CFLAGS ./configure prints:

  checking for fchdir... yes
  checking for fsync... yes
  checking for fdatasync... yes

so it is irrelevant what the OS is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:02:08 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Oct 2017 21:02:08 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507669328.92.0.213398074469.issue31728@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3919

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:14:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 21:14:24 +0000
Subject: [issue31748] configure fails to detect fchdir() using CFLAGS="-Werror
 -Wall"
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507670064.36.0.213398074469.issue31748@psf.upfronthosting.co.za>


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

I can reproduce the issue on Fedora 26:

haypo at selma$ ./configure CFLAGS="-Werror -Wall" 2>&1|tee log
haypo at selma$ grep fchdir log
checking for fchdir... no

The problem is not posixmodule.c. The problem is configure which emits a compiler warning.

configure.ac contains:
---
AC_MSG_CHECKING(for fchdir)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <unistd.h>]], [[void *x=fchdir]])],
  [AC_DEFINE(HAVE_FCHDIR, 1, Define if you have the 'fchdir' function.)
   AC_MSG_RESULT(yes)],
  [AC_MSG_RESULT(no)
])
---

Extract of config.log, without the long confdefs.h part:
---
configure:11258: checking for fchdir
configure:11271: gcc -c -Werror -Wall -Wextra  conftest.c >&5
conftest.c: In function 'main':
conftest.c:256:7: error: unused variable 'x' [-Werror=unused-variable]
 void *x=fchdir
       ^
cc1: all warnings being treated as errors
configure:11271: $? = 1
configure: failed program was:
| /* confdefs.h */
| (...)
| /* end confdefs.h.  */
| #include <unistd.h>
| int
| main ()
| {
| void *x=fchdir
|   ;
|   return 0;
| }
configure:11278: result: no
---

----------
title: Modules/posixmodule.c: skip compiling jka4NaPmmQ37 and posix_fildes_fd -> configure fails to detect fchdir() using CFLAGS="-Werror -Wall"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:15:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Oct 2017 21:15:16 +0000
Subject: [issue31748] configure fails to detect fchdir() using CFLAGS="-Werror
 -Wall"
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507670116.67.0.213398074469.issue31748@psf.upfronthosting.co.za>


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

Python 2.7 is also affected by the issue.

----------
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:29:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 21:29:28 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
Message-ID: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The following code causes an assertion error in timedelta constructor.

from datetime import timedelta

class BadInt(int):
    def __mul__(self, other):
        return Prod()

class Prod:
    def __radd__(self, other):
        return Sum()

class Sum:
    def __divmod__(self, other):
        return (0, -1)

timedelta(hours=BadInt(1))


Result:

python: /home/serhiy/py/cpython/Modules/_datetimemodule.c:1573: microseconds_to_delta_ex: Assertion `0 <= temp && temp < 1000000' failed.
Aborted (core dumped)

----------
components: Extension Modules
messages: 304083
nosy: Oren Milman, belopolsky, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Assertion failure in timedelta() in case of bad __divmod__
type: crash
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:33:56 2017
From: report at bugs.python.org (Rich)
Date: Tue, 10 Oct 2017 21:33:56 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507671236.13.0.213398074469.issue31749@psf.upfronthosting.co.za>


Rich <miserlou+python2 at gmail.com> added the comment:

Yep, as I mentioned, it should be configurable to use either format. Localization is an excellent point as well, so, all in all, the optional arguments to the function are format, significant digits, and delimiter. That's not an unreasonable amount of configurability.

It's not a complex problem, the solutions are fairly simple, but there are many ways to shoot yourself in the foot when rolling your own. There are already many packages which attempt this, most of which aren't used by any serious projects, who instead use their own implementations. There are just as many snippets of partial solutions floating around the internet as well. There is no canonical way to solve this common problem.

This is exactly why this common functionality should be added to the standard library, so that this extremely common function doesn't have to be imported from some-random-jamook's-untrustworthy-project-on-PyPI or rewritten from scratch for every project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:39:29 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Oct 2017 21:39:29 +0000
Subject: [issue31751] Support for C++ 11 and/or C++ 14 in python.org installer
In-Reply-To: <1507661476.93.0.213398074469.issue31751@psf.upfronthosting.co.za>
Message-ID: <1507671569.04.0.213398074469.issue31751@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Can you give a test case demonstrating what is not working?  The Python interpreters installed with python.org 10.6+ installers are built to work with all versions of macOS from 10.6 on and should be able to build extension modules with either gcc or clang as provided by the Xcode or Command Line Tools appropriate for the macOS version in use.  And, AFAIK, Python itself has no dependency on C++ at all so there should not be a c++ runtime library conflict due to Python itself.  Although the initial value of the configuration variables are CC=gcc-4.2 and GXX=g++-4.2, when the first compilation of an extension module is attempted, Distutils via Lib/_osx_support.py will do some work to figure out what compilers are available and modify CC and CXX accordingly.  So, for example, on say a macOS 10.13 system with the default Command Line Tools, it should use gcc and g++ which are both aliases for clang.  And, if necessary, you can always override the default compiler selection by explicitly setting the CC and/or CXX environment variables when invoking python.  At least that's how it's supposed to work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31751>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:42:00 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Oct 2017 21:42:00 +0000
Subject: [issue31746] crashes in sqlite3.Connection in case it is
 uninitialized or partially initialized
In-Reply-To: <1507645879.63.0.213398074469.issue31746@psf.upfronthosting.co.za>
Message-ID: <1507671720.43.0.213398074469.issue31746@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +3920
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31746>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:49:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 21:49:17 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1507672157.28.0.213398074469.issue31752@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3922

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:51:30 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 21:51:30 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507672290.95.0.213398074469.issue31728@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a8ac71d15f2a4aef83a8954a678cc12545ce517c by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31728: Prevent crashes in _elementtree due to unsafe cleanup of Element.text and Element.tail (GH-3924) (#3945)
https://github.com/python/cpython/commit/a8ac71d15f2a4aef83a8954a678cc12545ce517c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:53:00 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 10 Oct 2017 21:53:00 +0000
Subject: [issue31537] Bug in readline module documentation example
In-Reply-To: <1505938727.72.0.626220071672.issue31537@psf.upfronthosting.co.za>
Message-ID: <1507672379.99.0.213398074469.issue31537@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset eeb5ffd54e56dd89a99c74eb512c36d62649cfec by Mariatta (Brad Smith) in branch 'master':
bpo-31537: Update readline documentation example. (GH-3925)
https://github.com/python/cpython/commit/eeb5ffd54e56dd89a99c74eb512c36d62649cfec


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31537>
_______________________________________

From report at bugs.python.org  Tue Oct 10 17:54:12 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Oct 2017 21:54:12 +0000
Subject: [issue31537] Bug in readline module documentation example
In-Reply-To: <1505938727.72.0.626220071672.issue31537@psf.upfronthosting.co.za>
Message-ID: <1507672452.16.0.213398074469.issue31537@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3923

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31537>
_______________________________________

From report at bugs.python.org  Tue Oct 10 18:02:07 2017
From: report at bugs.python.org (Aaron Hall)
Date: Tue, 10 Oct 2017 22:02:07 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
Message-ID: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>


New submission from Aaron Hall <aaronchall at yahoo.com>:

Removing the closure seems to make the function about 10% faster.

Original source code at: https://github.com/python/cpython/blob/3.6/Lib/ast.py#L40

Empirical evidence: astle.py

import timeit
from ast import literal_eval as orig_literal_eval
from ast import *

def new_literal_eval(node_or_string):
    """
    Safely evaluate an expression node or a string containing a Python
    expression.  The string or node provided may only consist of the following
    Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
    sets, booleans, and None.
    """
    if isinstance(node_or_string, str):
        node_or_string = parse(node_or_string, mode='eval')
    if isinstance(node_or_string, Expression):
        node_or_string = node_or_string.body
    node = node_or_string
    if isinstance(node, Constant):
        return node.value
    elif isinstance(node, (Str, Bytes)):
        return node.s
    elif isinstance(node, Num):
        return node.n
    elif isinstance(node, Tuple):
        return tuple(map(_convert, node.elts))
    elif isinstance(node, List):
        return list(map(_convert, node.elts))
    elif isinstance(node, Set):
        return set(map(_convert, node.elts))
    elif isinstance(node, Dict):
        return dict((_convert(k), _convert(v)) for k, v
                    in zip(node.keys, node.values))
    elif isinstance(node, NameConstant):
        return node.value
    elif isinstance(node, UnaryOp) and isinstance(node.op, (UAdd, USub)):
        operand = _convert(node.operand)
        if isinstance(operand, _NUM_TYPES):
            if isinstance(node.op, UAdd):
                return + operand
            else:
                return - operand
    elif isinstance(node, BinOp) and isinstance(node.op, (Add, Sub)):
        left = _convert(node.left)
        right = _convert(node.right)
        if isinstance(left, _NUM_TYPES) and isinstance(right, _NUM_TYPES):
            if isinstance(node.op, Add):
                return left + right
            else:
                return left - right
    raise ValueError('malformed node or string: ' + repr(node))



def main():
    print('orig first, then new')
    print("'1.01'")
    print(min(timeit.repeat(lambda: orig_literal_eval('1.01'))))
    print(min(timeit.repeat(lambda: new_literal_eval('1.01'))))
    print("""'"1.01"'""")
    print(min(timeit.repeat(lambda: orig_literal_eval('"1.01"'))))
    print(min(timeit.repeat(lambda: new_literal_eval('"1.01"'))))
    print("'1'")
    print(min(timeit.repeat(lambda: orig_literal_eval('1'))))
    print(min(timeit.repeat(lambda: new_literal_eval('1'))))


if __name__ == '__main__':
    main()

Shell:

$ python -m astle
orig first, then new
'1.01'
3.518230145502848
3.274753015923377
'"1.01"'
3.189016693752965
2.906869704238048
'1'
3.40557457956146
3.157061471625788

----------
components: Library (Lib)
messages: 304089
nosy: Aaron Hall
priority: normal
severity: normal
status: open
title: Unnecessary closure in ast.literal_eval
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Tue Oct 10 18:03:16 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 10 Oct 2017 22:03:16 +0000
Subject: [issue31537] Bug in readline module documentation example
In-Reply-To: <1505938727.72.0.626220071672.issue31537@psf.upfronthosting.co.za>
Message-ID: <1507672996.81.0.213398074469.issue31537@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 10eb14e2c5fe08c4193668530eaef156e07c3674 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-31537: Update readline documentation example. (GH-3925) (GH-3948)
https://github.com/python/cpython/commit/10eb14e2c5fe08c4193668530eaef156e07c3674


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31537>
_______________________________________

From report at bugs.python.org  Tue Oct 10 18:04:12 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 10 Oct 2017 22:04:12 +0000
Subject: [issue31537] Bug in readline module documentation example
In-Reply-To: <1505938727.72.0.626220071672.issue31537@psf.upfronthosting.co.za>
Message-ID: <1507673052.51.0.213398074469.issue31537@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Fixed. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31537>
_______________________________________

From report at bugs.python.org  Tue Oct 10 18:20:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Oct 2017 22:20:51 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1507674051.87.0.213398074469.issue31753@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Test more complex examples including list and dict displays, binary operators.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:09:30 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 Oct 2017 23:09:30 +0000
Subject: [issue30457] Allow retrieve the number of waiters pending for most of
 the asyncio lock primitives
In-Reply-To: <1495637305.13.0.0526704297983.issue30457@psf.upfronthosting.co.za>
Message-ID: <1507676970.48.0.213398074469.issue30457@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Isn't this code equivalent to yours:

async def get(process, key):
    try:
        return cache[key]
    except KeyError:
        if key in events:
            await events[key].wait()
        else:
            events[key] = asyncio.Event()

            # simulates some IO to get the Key
            await asyncio.sleep(0.1)
            cache[key] = "some random value"
            event.set()

        return cache[key]


?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30457>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:24:44 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 10 Oct 2017 23:24:44 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507677884.56.0.213398074469.issue31749@psf.upfronthosting.co.za>


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

A library implementing this should definitely go on PyPI first to shake out design issues. Then we'd need a PEP.

As someone who has a simplistic version of this code around, and who's done a bit of string formatting, I can assure you that there are a lot of issues to be thought through.

- Should it be 0.5M, or 500K? Is there a cutoff to switch over? Is it configurable?
- What if I prefer 1000K to 1M? Or even 1,000.0K or 1.000,0K (localized)?
- How many decimals to display? Can you suppress trailing zeros? Should it be 1.0M, or 1M?
- Space between the number and the units?
- As you mention, MiB vs. MB. And there are schemes where MB means 1000^2 and others where MB means 2^20. And as Serhiy says, schemes where 1 MB = 1024000 bytes. How to handle all of these.
- Localization. Should this be specified as a locale, use the current locale, just ignored (see PEP 378 for an example), or have the delimiters passed in?

I'm sure there are other decisions to be made.

If you're serious about this (and I hope you are!), then I think finding current best practices both within and outside of the Python universe should be researched.

I do like the idea of the "h" format specifier, which would be an argument to move it in to the stdlib. That said, we never did come to agreement on something much simpler: engineering notation for floats (see issue 8060), because no one put the time into writing up a concrete proposal.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:43:12 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:43:12 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507678992.77.0.213398074469.issue31741@psf.upfronthosting.co.za>


Change by Chris Caron <lead2gold at gmail.com>:


Added file: https://bugs.python.org/file47205/Test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:44:41 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:44:41 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507679081.73.0.213398074469.issue31741@psf.upfronthosting.co.za>


Change by Chris Caron <lead2gold at gmail.com>:


Added file: https://bugs.python.org/file47206/site-packages-Directory.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:46:11 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:46:11 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507679171.24.0.213398074469.issue31741@psf.upfronthosting.co.za>


Change by Chris Caron <lead2gold at gmail.com>:


Added file: https://bugs.python.org/file47207/Test.Directory.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:47:27 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:47:27 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507679247.95.0.213398074469.issue31741@psf.upfronthosting.co.za>


Change by Chris Caron <lead2gold at gmail.com>:


Added file: https://bugs.python.org/file47208/Test.Script.Backports.Dir.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:48:00 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:48:00 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507679280.35.0.213398074469.issue31741@psf.upfronthosting.co.za>


Change by Chris Caron <lead2gold at gmail.com>:


Added file: https://bugs.python.org/file47209/Test.Script.Output.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:49:53 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:49:53 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507679393.26.0.213398074469.issue31741@psf.upfronthosting.co.za>


Change by Chris Caron <lead2gold at gmail.com>:


Added file: https://bugs.python.org/file47210/Python.Test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 19:57:27 2017
From: report at bugs.python.org (Chris Caron)
Date: Tue, 10 Oct 2017 23:57:27 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507679847.7.0.213398074469.issue31741@psf.upfronthosting.co.za>


Chris Caron <lead2gold at gmail.com> added the comment:

I'm not doing anything unusual.

Just to recap, I installed Python27 (in Windows 7 in my case- but this problem happens in Windows 10 too).

I did use `pip` to install packages as you'll see in the screenshot.  But even if i rename the `C:\Python27\Lib\site-packages\backports` to `ignoreme-backports`.  When i change the PYTHONPATH (from within sys.path.insert(0, 'new_path/that/has/a/backports/dir/in/it');

import backports
print backports.__path__
# always prints: C:\Python27\Lib\site-packages\backports

The problem arises because the following code won't work in my program:

from import import ssl_match_hostname

^^ That throws an exception that the package doesn't exist.  It's debugging it to the __path__ being incorrect that caused me to create this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Tue Oct 10 20:18:47 2017
From: report at bugs.python.org (Robert Snoeberger)
Date: Wed, 11 Oct 2017 00:18:47 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
Message-ID: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>


New submission from Robert Snoeberger <robert.snoeberger at me.com>:

The signature for PyBuffer_FillContiguousStrides in the documentation shows that the type of parameter 'itemsize' is Py_ssize_t [1]. This is different from the signature in Include/abstract.h which shows that the type as int [2].


[1] https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_FillContiguousStrides
[2] https://github.com/python/cpython/blob/49b2734bf12dc1cda80fd73d3ec8896ae3e362f2/Include/abstract.h#L559-L563

----------
assignee: docs at python
components: Documentation
messages: 304096
nosy: docs at python, snoeberger
priority: normal
severity: normal
status: open
title: Documented type of parameter 'itemsize' to PyBuffer_FillContiguousStrides is incorrect.
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Tue Oct 10 20:35:38 2017
From: report at bugs.python.org (Amber Brown)
Date: Wed, 11 Oct 2017 00:35:38 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507682138.3.0.213398074469.issue31742@psf.upfronthosting.co.za>


Amber Brown <hawkowl at atleastfornow.net> added the comment:

> What happened to "consenting adults"?

Consent does not mean that by using Python, users fully consent to using modules that they may not be aware will, to paraphrase Donald, come back to bite them in the ass.

Consent requires multiple things:

- Acknowledgement of the benefits involved
- Acknowledgement of the risks involved
- Positive affirmation that these things are accepted.

The spate of PyCon talks on provisional modules (the half dozen asyncio at PyCon US last year, and the 2-3+ asyncio talks at every conference I've been to since 2014) very much has given the community the first item, and as people have expressed interest in the benefits, acknowledge them.

But, CPython does not like at all admitting clearly or explicitly the risks involved. From multiple discussions with Nick, an author of the provisional API PEP, it has come clear to me that the intended role of provisional software is to allow CPython to ship not-production-ready software for testing and API usability testing in an experimental capacity. How many people, from reading the single line in the docs (which, remember, is not the only path where people learned how to use asyncio in 3.4/3.5, and is absent from module documentation), did not know this?

Upon discussing this issue with others, a few people admitted that they had no idea that provisional APIs existed, that asyncio was one, that typing is one, and they had no idea where to look to see if they were using a provisional module in their code or their dependencies.

So, it appears that CPython is failing item #2 here, by not adequately informing users of the risks. Yes, the warning should be improved (and ought to be made bright red, not grey, and actually use the word "warning", not note), but we should also take a step to protect the users that may not learn about the module through official documentation, and in some cases, may never reference it.

Only then can we confidently say that the user is potentially a "consenting adult". (Which is maybe interesting language to use nowadays considering Python's growth areas contain a lot of school-age education...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Tue Oct 10 21:45:27 2017
From: report at bugs.python.org (steven Michalske)
Date: Wed, 11 Oct 2017 01:45:27 +0000
Subject: [issue31751] Support for C++ 11 and/or C++ 14 in python.org installer
In-Reply-To: <1507671569.04.0.213398074469.issue31751@psf.upfronthosting.co.za>
Message-ID: <FAAD355F-D6EE-4F2E-AA20-314CE8870D32@gmail.com>


steven Michalske <smichalske at gmail.com> added the comment:

This might be a cython issue then, but I will dig into an example case.  Please be patient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31751>
_______________________________________

From report at bugs.python.org  Tue Oct 10 22:13:11 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Oct 2017 02:13:11 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507687991.44.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've been thinking further about the write-through proxy idea, and I think I've come up with a design for one that shouldn't be too hard to implement, while also avoiding all of the problems that we want to avoid.

The core of the idea is that the proxy type would just be a wrapper around two dictionaries:

- the existing f_locals dictionary
- a new dictionary mapping cell & free variable names to their respective cells (note: this may not actually need to be a dict, as a direct reference from the proxy back to the frame may also suffice. However, I find it easier to think about the design by assuming this will be a lazily initialised dict in its own right)

Most operations on the proxy would just be passed through to f_locals, but for keys in both dictionaries, set and delete operations would *also* affect the cell in the cell dictionary. (Fortunately dict views don't expose any mutation methods, or intercepting all changes to the mapping would be a lot trickier)

Frames would gain a new lazily initialised "f_traceproxy" field that defaults to NULL/None.

For code objects that don't define or reference any cells, nothing would change relative to today.

For code objects that *do* define or reference cells though, tracing would change as follows:

* before calling the trace function:
  - f_locals would be updated from the fast locals array and current cell values as usual
  - f_locals on the frame would be swapped out for f_traceproxy (creating the latter if needed)
* after returning from the trace function:
  - f_locals on the frame would be reset back to bypassing the proxy (so writes to f_locals stop being written through to cells when the trace hook isn't running)
  - only the actual locals would be written from f_locals back to the fast locals array (cell updates are assumed to have already been handled via the proxy)

This preserves all current behaviour *except* the unwanted one of resetting cells back to their pre-tracehook value after returning from a trace hook:

* code outside trace hooks can't mutate the function level fast locals or cells via locals() or frame.f_locals (since their modifications will be overwritten immediately before the trace function runs), but *can* treat it as a regular namespace otherwise
* code inside trace hooks can mutate function level fast locals and cells just by modifying frame.f_locals
* all code can display the current value of function level fast locals and cells just by displaying locals() or frame.f_locals
* there's still only one f_locals dictionary per frame, it may just have a proxy object intercepting writes to cell variables when a trace hook is running

That way, we can avoid the problem with overwriting cells back to old values, *without* enabling arbitrary writes to function locals from outside trace functions, and without introducing any tricky new state synchronisation problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Tue Oct 10 22:16:40 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Oct 2017 02:16:40 +0000
Subject: [issue17960] Clarify the required behaviour of locals()
In-Reply-To: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za>
Message-ID: <1507688200.43.0.213398074469.issue17960@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Nathaniel raised a valid concern about the draft PEP over in https://bugs.python.org/issue30744#msg302475, so I've been considering whether or not it would be possible to make the write-through proxy idea work without introducing other problems.

I think I have a workable design concept for that approach now: https://bugs.python.org/issue30744#msg304099

So the next step will be to see if that actually does work as well as I think it will, and if so, update the PEP accordingly.

----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17960>
_______________________________________

From report at bugs.python.org  Tue Oct 10 22:34:11 2017
From: report at bugs.python.org (Aaron Hall)
Date: Wed, 11 Oct 2017 02:34:11 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1507689251.75.0.213398074469.issue31753@psf.upfronthosting.co.za>


Aaron Hall <aaronchall at yahoo.com> added the comment:

Rejecting and withdrawing with apologies.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Tue Oct 10 22:47:10 2017
From: report at bugs.python.org (Brad Smith)
Date: Wed, 11 Oct 2017 02:47:10 +0000
Subject: [issue31456] SimpleCookie fails to parse any cookie if an entry has
 whitespace in the name
In-Reply-To: <1505328383.45.0.696771060303.issue31456@psf.upfronthosting.co.za>
Message-ID: <1507690030.69.0.213398074469.issue31456@psf.upfronthosting.co.za>


Brad Smith <brad82 at gmail.com> added the comment:

According to RFC-6265 (which also references RFC-2616 to define "tokens"), the space character (and whitespace in general) is not valid in cookie-names or cookie-values.

RFC-6265: https://tools.ietf.org/html/rfc6265#section-4.1.1
RFC-2616: https://tools.ietf.org/html/rfc2616#section-2.2

I think it's reasonable for Python to quietly throw away malformed NAME=VALUE pairs since web browsers are likely doing the same.

----------
nosy: +infinitewarp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31456>
_______________________________________

From report at bugs.python.org  Tue Oct 10 23:08:34 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 11 Oct 2017 03:08:34 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507691314.93.0.213398074469.issue31742@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm still trying to understand whether there's a specific event (or set of events) that's triggered this issue. There is a lot of talk about people can be misled but not a single specific example of someone who actually got in trouble because a provisional API they were actually using changed.

Given the passion I read in some of the comments it shouldn't be hard to collect such stories?

As with every other change proposed to Python, unless there's a clear indication that there is an actual problem, I'm not inclined to try to solve it preemptively (since the proposed action also may *introduce* new problems). Note that I'm not asking for proof that some people don't know what provisional means -- I'm looking for evidence of actual situations where someone got bitten.

Also I don't think that people who didn't read the docs have much of a leg to stand on. There are plenty of situations where subtle aspects of APIs are not guaranteed to be stable (e.g. calling a function with a value that the docs say is invalid but that is not actively rejected by some version). And nobody can expect that a talk (no matter how clearly presented) is a substitute for reading the docs -- a talk on a complex API like asyncio or typing cannot possibly cover the whole API (I know, I've tried :-).

That said, we should absolutely change the warnings in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Wed Oct 11 00:06:24 2017
From: report at bugs.python.org (Adam Davis)
Date: Wed, 11 Oct 2017 04:06:24 +0000
Subject: [issue31456] SimpleCookie fails to parse any cookie if an entry has
 whitespace in the name
In-Reply-To: <1505328383.45.0.696771060303.issue31456@psf.upfronthosting.co.za>
Message-ID: <1507694784.77.0.213398074469.issue31456@psf.upfronthosting.co.za>


Adam Davis <adamdavis40208 at gmail.com> added the comment:

Quietly throw out the one bad value, sure. You lose all cookies in your cookie string in this scenario. 

I'd expect "ASDF=stuff; ASDF space=more stuff" to at least kick out the values that are legal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31456>
_______________________________________

From report at bugs.python.org  Wed Oct 11 00:51:03 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 11 Oct 2017 04:51:03 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1507650363.61.0.213398074469.issue31314@psf.upfronthosting.co.za>
Message-ID: <CA+Z=B_nYoR2QpqvKpCkMBrrMeGitQaQD4YTng_eDGXcatNduzA@mail.gmail.com>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I found that when email header's self._firstlinelen value is negative
then self._split() returns an empty list.
Because when the self._firstlinelen value is negative value then
'targetlen' becomes a negative value.

I will update a patch into calculating self.firstlinelen as same as Python3.

2017-10-11 0:46 GMT+09:00 Serhiy Storchaka <report at bugs.python.org>:
>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> PR 3938 fixes this issue, but I'm wondering why self._split() returns an empty list only for long header names.
>
> ----------
> nosy: +serhiy.storchaka
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31314>
> _______________________________________

-- 
Chungnam National University | Computer Science & Engineering

Tel: +82 010-3353-9127
Email: donghee.na92 at gmail.com
Linkedin: https://www.linkedin.com/in/dong-hee-na-2b713b49/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Wed Oct 11 01:33:11 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Oct 2017 05:33:11 +0000
Subject: [issue14369] make __closure__ writable
In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za>
Message-ID: <1507699991.95.0.213398074469.issue14369@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This still seems like a reasonable enhancement, but would presumably need updates to apply against the 3.7 development branch.

----------
versions: +Python 3.7 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14369>
_______________________________________

From report at bugs.python.org  Wed Oct 11 01:50:13 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 11 Oct 2017 05:50:13 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <CA+Z=B_nYoR2QpqvKpCkMBrrMeGitQaQD4YTng_eDGXcatNduzA@mail.gmail.com>
Message-ID: <CA+Z=B_mbP7mQNAddoKFFtNdCB_2Db9na3zZ-gUb2fa-P_-QKxw@mail.gmail.com>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

And my patch was wrong, I will re-upload it soon.

2017-10-11 13:51 GMT+09:00 Dong-hee Na <report at bugs.python.org>:
>
> Dong-hee Na <donghee.na92 at gmail.com> added the comment:
>
> I found that when email header's self._firstlinelen value is negative
> then self._split() returns an empty list.
> Because when the self._firstlinelen value is negative value then
> 'targetlen' becomes a negative value.
>
> I will update a patch into calculating self.firstlinelen as same as Python3.
>
> 2017-10-11 0:46 GMT+09:00 Serhiy Storchaka <report at bugs.python.org>:
>>
>> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>>
>> PR 3938 fixes this issue, but I'm wondering why self._split() returns an empty list only for long header names.
>>
>> ----------
>> nosy: +serhiy.storchaka
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <https://bugs.python.org/issue31314>
>> _______________________________________
>
> --
> Chungnam National University | Computer Science & Engineering
>
> Tel: +82 010-3353-9127
> Email: donghee.na92 at gmail.com
> Linkedin: https://www.linkedin.com/in/dong-hee-na-2b713b49/
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31314>
> _______________________________________

-- 
Chungnam National University | Computer Science & Engineering

Tel: +82 010-3353-9127
Email: donghee.na92 at gmail.com
Linkedin: https://www.linkedin.com/in/dong-hee-na-2b713b49/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Wed Oct 11 02:26:40 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Oct 2017 06:26:40 +0000
Subject: [issue14369] make __closure__ writable
In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za>
Message-ID: <1507703200.89.0.213398074469.issue14369@psf.upfronthosting.co.za>


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


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14369>
_______________________________________

From report at bugs.python.org  Wed Oct 11 02:27:57 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Oct 2017 06:27:57 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507703277.89.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A note regarding applicability if we did make a change to our approach:

* asyncio & pathlib are already non-provisional, so wouldn't be affected.

* typing is still provisional, but introducing a new FutureWarning after two releases without one would be problematic, so we should probably leave it alone and only apply a policy change (if we make one) to *new* provisional APIs

* the main open proposal we have for a new provisional API in 3.7 is for the interpreters module in PEP 554 (as we don't expect either execution contexts or data classes to need to be provisional). Defaulting to emitting a FutureWarning for that would be appropriate, since we already expect there to be changes over time in the way it interacts with the threading module. Accordingly, I've added Eric Snow to the nosy list here, since it's his PEP that would be most directly affected (it would need to define a new "__main__.use_provisional_interpreters" feature flag, and emit a FutureWarning on import if that wasn't set).


The specific cases of our current approach to handling provisional APIs causing problems for others that came up in the original discussion were:

* third party libraries (e.g. Twisted, Django) being pressured by their users to add asyncio support while asyncio was still provisional. This pushed the burden of explaining what CPython's provisional API status actually means on to the developers of those libraries, including the implication that the community support period for any particular version of the provisional API may end up being measured in months rather than the years typically implied by inclusion in the CPython standard library.
* developers & users of the cattrs package getting caught by surprise when backwards incompatible changes were made to the typing module

So this RFE is about ensuring that we have *adequately informed* consent when people opt-in to the more demanding requirements of using provisional APIs (i.e. you need to be able to reliably track the latest version, and if you and your users aren't in a position to commit to that, it's desirable to either not support them at all, or else treat support for them as an optional add-on until they're declared stable).

It's also about helping to ensure that when folks do have questions about what it means for a Python API to be provisional, they come to *us* (the CPython core developers that are actually working on those provisional APIs) with their questions, rather than hassling third party library developers that are just trying to keep up with the related changes.

For syntactic changes, we already have __future__ imports as a way for people to declare informed consent and adopt features early.

We don't currently have a comparable mechanism for provisional APIs - we're just assuming that everyone advocating for early adoption of the API will also be including the appropriate caveats around the fact that it's provisional, and that this may place additional burdens on both end users attempting to use it, and third party libraries attempting to support it.

We've had 5 years of experience with the provisional API R&D model now, and while some of the uses haven't caused any ecosystem level problems that we're aware of (e.g. pathlib), two of the more high profile uses (asyncio & typing) *have* caused problems, and at least some of those problems can be attributed to the fact that it's easy for people to learn of and start using a provisional API without ever looking at the standard library module documentation for it:

- they may be following something they saw in a talk
- they may be following an answer from Stack Overflow
- they may be following a blog post or 3rd party guide rather than the standard library documentation
- they may be following the documentation for a 3rd party libary or framework

As a result, merely importing a provisional API doesn't really qualify as giving appropriately informed consent, while silencing a FutureWarning that's emitted by default *does*: the act of silencing the warning means that either they've read the warning themselves and decided to silence it, or else they've silenced it based on someone else's advice.

This differs from DeprecationWarnings, since we know from experience (most recently with the initially proposed warnings in the locale coercion PEP) that any kind of new output on stderr can sometimes break working code. Making those opt-in thus meant that we could continue adding them as needed, but developers would be in control of when and where they actually appear (e.g. only in their test systems, instead of on end user's machines).

With FutureWarnings for provisional APIs, we'd be aiming to encourage a couple of key behaviours:

- for direct use in scripts and application code, set the feature flag when first adding an import of the provisional API, and have this guidance be a standard part of all third party introductions to using the provisional API
- for third party libraries, either only import provisional APIs when their own users explicitly opt-in to using related experimental features, or else inform their users that they should set the feature flag appropriately when depending on the library

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Wed Oct 11 02:31:23 2017
From: report at bugs.python.org (pfreixes)
Date: Wed, 11 Oct 2017 06:31:23 +0000
Subject: [issue30457] Allow retrieve the number of waiters pending for most of
 the asyncio lock primitives
In-Reply-To: <1495637305.13.0.0526704297983.issue30457@psf.upfronthosting.co.za>
Message-ID: <1507703483.18.0.213398074469.issue30457@psf.upfronthosting.co.za>


pfreixes <pfreixes at gmail.com> added the comment:

Not really, your code never removes the key from the events. If the cache is cleaned all further executions will keep forever in the `wait` statement. It is needed to create the Event again to perform at least one query to retrieve the cache value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30457>
_______________________________________

From report at bugs.python.org  Wed Oct 11 02:35:02 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 11 Oct 2017 06:35:02 +0000
Subject: [issue30457] Allow retrieve the number of waiters pending for most of
 the asyncio lock primitives
In-Reply-To: <1495637305.13.0.0526704297983.issue30457@psf.upfronthosting.co.za>
Message-ID: <1507703702.46.0.213398074469.issue30457@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Not really, your code never removes the key from the events. If the cache is cleaned all further executions will keep forever in the `wait` statement. It is needed to create the Event again to perform at least one query to retrieve the cache value.

Right.  Well, that should be solved by adding "events.pop(key)" right after "events[key].set()"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30457>
_______________________________________

From report at bugs.python.org  Wed Oct 11 03:36:55 2017
From: report at bugs.python.org (pfreixes)
Date: Wed, 11 Oct 2017 07:36:55 +0000
Subject: [issue30457] Allow retrieve the number of waiters pending for most of
 the asyncio lock primitives
In-Reply-To: <1495637305.13.0.0526704297983.issue30457@psf.upfronthosting.co.za>
Message-ID: <1507707415.81.0.213398074469.issue30457@psf.upfronthosting.co.za>


pfreixes <pfreixes at gmail.com> added the comment:

You are right, having the `pop` after the `set` it would remove the key from the events. Despite the workaround that you proposes is quite clean, it is kinda implicit.

The nature of the `pending` method is to give to the developer a way to check how many waiters are still pending. This not only helps to make this code more explicit also other pieces of code that might need access to the length of the waiters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30457>
_______________________________________

From report at bugs.python.org  Wed Oct 11 03:45:29 2017
From: report at bugs.python.org (Kenji Asuka (Asuka Kenji))
Date: Wed, 11 Oct 2017 07:45:29 +0000
Subject: [issue31755] SetType is missing in the 'types' module
Message-ID: <1507707929.59.0.213398074469.issue31755@psf.upfronthosting.co.za>


New submission from Kenji Asuka (Asuka Kenji) <asukakenji at gmail.com>:

# Create a dict and a set
d = {1: '1'}
s = {1}

# They have different types
print(type(d))             # <type 'dict'>
print(type(s))             # <type 'set'>
print(type(d) is type(s))  # False
print(type(s) is type(d))  # False
print(type(d) == type(s))  # False

# Dictionary type is found in 'types' module
print(type(d) is types.DictType)               # True
print(type(d) is types.DictionaryType)         # True
print(types.DictType == types.DictionaryType)  # True

# Set type is not found in 'types' module
print(type(s) is types.DictType)            # False
print(type(s) is types.DictionaryType)      # False
print(type(s) is types.DictProxyType)       # False
print(type(s) is types.ListType)            # False
print(type(s) is types.SliceType)           # False
print(type(s) is types.TupleType)           # False
print(type(s) is types.NotImplementedType)  # False
print(type(s) is types.SetType)             # AttributeError: 'module' object has no attribute 'SetType'

----------
components: Library (Lib)
messages: 304112
nosy: Kenji Asuka (Asuka Kenji)
priority: normal
severity: normal
status: open
title: SetType is missing in the 'types' module
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31755>
_______________________________________

From report at bugs.python.org  Wed Oct 11 03:52:44 2017
From: report at bugs.python.org (Kenji Asuka (Asuka Kenji))
Date: Wed, 11 Oct 2017 07:52:44 +0000
Subject: [issue31755] SetType is missing in the 'types' module
In-Reply-To: <1507707929.59.0.213398074469.issue31755@psf.upfronthosting.co.za>
Message-ID: <1507708364.07.0.213398074469.issue31755@psf.upfronthosting.co.za>


Kenji Asuka (Asuka Kenji) <asukakenji at gmail.com> added the comment:

'set' is a built-in type, and should belong to one of the types in the 'types' module. However, in the latest 2.7 implementations, none of the names matches the 'set' type.

Like 'list' and 'dict', I suppose there should be a name 'SetType' in the 'types' module. However, I guess it was forgotten to be created when the '{x: y}' syntax was introduced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31755>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:02:35 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 11 Oct 2017 08:02:35 +0000
Subject: [issue31755] SetType is missing in the 'types' module
In-Reply-To: <1507707929.59.0.213398074469.issue31755@psf.upfronthosting.co.za>
Message-ID: <1507708955.94.0.213398074469.issue31755@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

The types modules is not suppose to hold all known types. It only contains types that are not available as builtin. The DictType member is a relict from the past. Before Python 2.2, the dict builtin and dict type were different things.

In Python 3, the types module no longer has DictType, IntType etc.

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31755>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:10:10 2017
From: report at bugs.python.org (Paul Moore)
Date: Wed, 11 Oct 2017 08:10:10 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507709410.65.0.213398074469.issue31741@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

> I did use `pip` to install packages as you'll see in the screenshot.

Sorry, I don't see any pip commands. Please could you include sample commands inline as text, and not as screenshots, as attached files aren't accessible from emails...

As I say, I suspect the backports module is being imported before you change sys.path, and hence your sys.path change isn't affecting it.

Sorry, but unless you can provide a precise set of steps to reproduce the issue, starting from the point where you install Python, I'm not sure what else we can do to help (but I will reiterate - this is *not* a problem with the Python install itself - we don't ship a site-packages/backports directory, that came with something you installed via pip).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:23:22 2017
From: report at bugs.python.org (Kenji Asuka (Asuka Kenji))
Date: Wed, 11 Oct 2017 08:23:22 +0000
Subject: [issue31755] SetType is missing in the 'types' module
In-Reply-To: <1507707929.59.0.213398074469.issue31755@psf.upfronthosting.co.za>
Message-ID: <1507710202.07.0.213398074469.issue31755@psf.upfronthosting.co.za>


Kenji Asuka (Asuka Kenji) <asukakenji at gmail.com> added the comment:

You wrote:

> It only contains types that are not available as builtin.

I think the opposite is true.


As shown in the "Versions" field in the issue, this bug is Python 2 specific, so there is nothing to do with Python 3.

My point is not on 'dict', but on 'set'. So the history of 'dict' doesn't care.

As we can see there are names for:
- 'None' (types.NoneType)
- 'bool' (types.BooleanType)
- 'int' (types.IntType)
- 'long' (types.LongType)
- 'float' (types.FloatType)
- 'complex' (types.ComplexType)
- etc.

and more importantly:
- 'tuple' (types.TupleType)
- 'list' (types.ListType)
- 'dict' (types.DictType)

and since 'set' is also considered a built-in type (see https://docs.python.org/2/library/stdtypes.html), I can't see the reason WHY it is not considered a bug without having 'set' (types.SetType) in the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31755>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:31:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 08:31:28 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1507710688.7.0.213398074469.issue25612@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I tried the following code:

def g():
    yield 1
    raise
    yield 2

i = g()
try:
    1/0
except:
    next(i)
    next(i)

Currently it raises:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
  File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero

With PR 1773 applied it raises:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
  File "<stdin>", line 3, in g
RuntimeError: No active exception to reraise

And this looks more correct.

But if replace raise with print(sys.exc_info()) the patched and unpatched interpreters both print:

(<class 'ZeroDivisionError'>, ZeroDivisionError('division by zero',), <traceback object at 0x7f61d9ed1448>)

Is it correct that sys.exc_info() return an exception while raise can't reraise it?

----------
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:41:48 2017
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 11 Oct 2017 08:41:48 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1507711308.79.0.213398074469.issue6135@psf.upfronthosting.co.za>


Andrew Clegg <andrew.clegg at durham.ac.uk> added the comment:

I meant the former; I'll look a bit more at the documentation and submit an issue/patch.

As regards the 'text' flag - universal_newlines is actually exactly that already. I've just checked the code of subprocess.py and the universal_newlines argument is read in only two places:
* as one of the deciding factors in whether to use the text mode
* in a backwards compatibility clause in check_output

So subprocess *already* has a text mode and a 'magic option' to trigger it. It works well, and is useful in most cases. When the default encoding guess is incorrect, it can easily be corrected by supplying the correct encoding. This is a good situation!

What is not so good is the API. I'm teaching a Python course for scientists at the moment. Retrieving text from external processes is an extremely common use case. I would rather not teach them to just have to use 'encoding=utf-8', because arguably teaching a user to supply an encoding without knowing if it's correct is worse than the system guessing. Equally, teaching 'universal_newlines=True' is a bit obscure.

The way forward seems to be:
* Add a text=True/False argument that is essentially the same as universal_newlines, to improve the API.
* Clearly document that this implies that the encoding will be guessed, and that an explicit encoding can be given if the guess is wrong
* Optionally, and I have no strong feelings either way on this, remove/deprecate the universal_newlines argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:43:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 08:43:19 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507711399.67.0.213398074469.issue31728@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: patch review -> backport needed
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:44:09 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 11 Oct 2017 08:44:09 +0000
Subject: [issue31748] configure fails to detect fchdir() using CFLAGS="-Werror
 -Wall"
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507711449.92.0.213398074469.issue31748@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +3924
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:45:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 08:45:47 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1507711547.4.0.213398074469.issue31754@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Wed Oct 11 04:55:25 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Oct 2017 08:55:25 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1507712125.02.0.213398074469.issue6135@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This discussion should probably be submitted as a new RFE (requesting "text" as a more obvious and beginner friendly alias for universal_newlines), but I'll also add a note regarding precedent for a simple binary/text toggle: the mode settings for open().

There, the default is text (with the default encoding determined by the system), and you have to include "b" in the mode settings to say "I want raw binary".

For the subprocess APIs, the default is different (i.e. binary), so the natural counterpart to the "b" mode flag in open() would be an explicit "text" mode flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Wed Oct 11 05:02:24 2017
From: report at bugs.python.org (Rafael Ascensao)
Date: Wed, 11 Oct 2017 09:02:24 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1507712544.71.0.213398074469.issue17088@psf.upfronthosting.co.za>


Rafael Ascensao <rafa.almas at gmail.com> added the comment:

what's the status on this?

----------
nosy: +Rafael Ascensao

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17088>
_______________________________________

From report at bugs.python.org  Wed Oct 11 05:16:32 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Wed, 11 Oct 2017 09:16:32 +0000
Subject: [issue31748] configure fails to detect fchdir() using CFLAGS="-Werror
 -Wall"
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507713392.03.0.213398074469.issue31748@psf.upfronthosting.co.za>


????? ???????? <dilyan.palauzov at aegee.org> added the comment:

The patch puts in "Misc/NEWS.d/next/Core and Builtins/2017-10-11-10-42-02.bpo-31748.oaEZcq.rst":

+Support configure with -Wall by avoiding unused variables.

but likely means "-Werror" (or both)

Different people generate ./configure different ways.  Some insert runstatedir in configure, others don't.  E.g. on 14 April 2017 runstatedir was added to configure, on 9 June it was removed from configure, on 29 June it was added to configure.  It needs to be clarified once forever, whether runstatedir belongs to configure or not and then everybody has to stick to this, in order to avoid useless changes in the version control.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Wed Oct 11 05:27:46 2017
From: report at bugs.python.org (Brian Sidebotham)
Date: Wed, 11 Oct 2017 09:27:46 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <1507714066.84.0.213398074469.issue31744@psf.upfronthosting.co.za>


Brian Sidebotham <brian at wanless-systems.com> added the comment:

I'm not sure any of my emails came through to this ticket from my mail client. I think this can be closed and filed under "not a bug".

Here are the mails I sent.:

Hi Marc-Andre,

Thanks for engaging.

I fixed RPATH and now things are building successfully:

LDFLAGS='-Wl,-rpath=\\$$\$$ORIGIN/../lib' \
./configure --prefix=/opt/wsl \
            --enable-shared \
            --with-system-ffi \
            --with-ensurepip=yes \
            --enable-optimizations

Thank-you for your help.

Best Regards,

Brian.


-----

Hi Charalampos,

We're building for RHEL7 on the latest version.

-bash-4.2$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.4 (Maipo)

Best Regards,

Brian.


----


Hi Ned,

Thank-you for your advice. There was no python2 installed on the build box in /opt/wsl. Fixing the RPATH reference appears to have fixed the problem. Perhaps something in the makefile was getting eaten by the crazy escaping to get ORIGIN in the python executable. Now it looks correct:
-bash-4.2$ readelf -d ./python 

Dynamic section at offset 0x3cd0 contains 31 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libpython2.7.so.1.0]
...
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib]

Best Regards,

Brian.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Wed Oct 11 05:30:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Oct 2017 09:30:09 +0000
Subject: [issue31748] configure fails to detect fchdir() using CFLAGS="-Werror
 -Wall"
In-Reply-To: <1507655150.66.0.213398074469.issue31748@psf.upfronthosting.co.za>
Message-ID: <1507714209.49.0.213398074469.issue31748@psf.upfronthosting.co.za>


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

"Different people generate ./configure different ways.  Some insert runstatedir in configure, others don't.  E.g. on 14 April 2017 runstatedir was added to configure, on 9 June it was removed from configure, on 29 June it was added to configure.  It needs to be clarified once forever, whether runstatedir belongs to configure or not and then everybody has to stick to this, in order to avoid useless changes in the version control."

For practical reasons, we decided to include the generated file configure in Git. You are right that not all developers use the same autoconf version, and so that the generated file includes or not the runstatedir change. I don't know how to fix this issue. If you consider that it's a bug and should be fixed, please open a new dedicated issue, since it's unrelated to your fchdir + -Werror bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31748>
_______________________________________

From report at bugs.python.org  Wed Oct 11 05:54:04 2017
From: report at bugs.python.org (Amber Brown)
Date: Wed, 11 Oct 2017 09:54:04 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507715644.36.0.213398074469.issue31742@psf.upfronthosting.co.za>


Amber Brown <hawkowl at atleastfornow.net> added the comment:

> * asyncio & pathlib are already non-provisional, so wouldn't be affected.

I was reading this and actually said "wait what I didn't know pathlib was provisional", and went back to check. The warning for it was grey next to a pair of yellow ones, no wonder I didn't see it.

I guess we can all agree that the provisional warning should be modified to be more obvious, at least. What's required in doing that? Just editing what's there, or is there some form of template that is used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Wed Oct 11 06:16:51 2017
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 11 Oct 2017 10:16:51 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
Message-ID: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>


New submission from Andrew Clegg <andrew.clegg at durham.ac.uk>:

Following on from https://bugs.python.org/issue6135

The subprocess module by default returns bytes from subprocess calls. It has a text mode, but this can only be accessed by slightly tangential arguments (setting encoding, errors or universal_newlines).

ncoghlan notes in msg304118 that this is a similar situation to the binary/text mode settings for open(). From the docs " In text mode, if encoding is not specified the encoding used is platform dependent: locale.getpreferredencoding(False) is called to get the current locale encoding"

The universal_newlines argument now effectively just turns on the text mode, however this is not an intuitively and obviously discoverable. So to improve usability, and to mirror the file opening behaviour, subprocess calls should be *explicitly* dual mode (binary/text), and have an explicitly named argument to control this.

My enhancement suggestion is as follows:
* Add a text=True/False argument that is an alias of universal_newlines, to improve the API.
* Clearly document that this implies that the encoding will be guessed, and that an explicit encoding can be given if the guess is wrong

For completeness, the following changes could also be made, although these may be controversial
* Remove/deprecate the universal_newlines argument
* Revert the default mode to text (as in Python 2.7), and have a binary=True argument instead

----------
components: Library (Lib)
messages: 304125
nosy: andrewclegg, ncoghlan, steve.dower
priority: normal
severity: normal
status: open
title: subprocess.run should alias universal_newlines to text
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Wed Oct 11 06:17:58 2017
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 11 Oct 2017 10:17:58 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1507717078.86.0.213398074469.issue6135@psf.upfronthosting.co.za>


Andrew Clegg <andrew.clegg at durham.ac.uk> added the comment:

RFE submitted as issue31756 , thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Wed Oct 11 06:27:11 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 10:27:11 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507717631.71.0.213398074469.issue31728@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
pull_requests: +3925
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Wed Oct 11 06:36:16 2017
From: report at bugs.python.org (Richard Aplin)
Date: Wed, 11 Oct 2017 10:36:16 +0000
Subject: [issue1566331] Bad behaviour in <ossaudio audio device>.obuf*
Message-ID: <1507718176.36.0.213398074469.issue1566331@psf.upfronthosting.co.za>


Richard Aplin <drtune at gmail.com> added the comment:

Hi there yes this is very much an issue on Arm linux (e.g. Armbian). Calling any function that triggers a call to _ssize(..) - a function which is clearly intended to have no side-effects - instead resets the number of channels (and sample format?) by calling IOCTLs "SNDCTL_DSP_SETFMT" and "SNDCTL_DSP_CHANNELS" with arguments of zero as a way to query the current values. 

This doesn't work on many drivers; e.g. they take '0' as meaning 'mono' and switch to one channel. 

To repro:
        import ossaudiodev
        self.dsp=ossaudiodev.open("/dev/dsp1","w")
        self.dsp.setfmt(ossaudiodev.AFMT_S16_LE)
        self.dsp.channels(2)  #<<Set to stereo
        self.dsp.speed(96000)
        ...
        self.bufSize=self.dsp.bufsize()
        ...

        #This will output audio in the wrong format (mono)! Remove the innocent looking "bufsize" test above and it will correctly output stereo
        self.dsp.write(someData)


Frustrating bug! ;-)

----------
nosy: +richaplin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1566331>
_______________________________________

From report at bugs.python.org  Wed Oct 11 07:14:09 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 11 Oct 2017 11:14:09 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1504175392.51.0.871887341171.issue31314@psf.upfronthosting.co.za>
Message-ID: <1507720449.38.0.213398074469.issue31314@psf.upfronthosting.co.za>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -3911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Wed Oct 11 07:53:30 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 11:53:30 +0000
Subject: [issue31271] an assertion failure in io.TextIOWrapper.write
In-Reply-To: <1503597989.21.0.785820469546.issue31271@psf.upfronthosting.co.za>
Message-ID: <1507722810.06.0.213398074469.issue31271@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
pull_requests: +3926
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31271>
_______________________________________

From report at bugs.python.org  Wed Oct 11 08:33:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Oct 2017 12:33:02 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1507725182.68.0.213398074469.issue10496@psf.upfronthosting.co.za>


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

user.py: short Python script to reproduce the bug. It runs Python as user 12345, group 12345 and unset the HOME environment variable to reproduce the bug.

The python binary must be readable and executable by any user, especially uid 12345 gid 12345. On my Fedora, /home/haypo is only accessible by the usr haypo. I cloned Python in /opt/cpython to work around the issue.

I confirm that Python 3.7 still has the bug.

----------
Added file: https://bugs.python.org/file47211/user.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:00:34 2017
From: report at bugs.python.org (Max Rothman)
Date: Wed, 11 Oct 2017 13:00:34 +0000
Subject: [issue30821] unittest.mock.Mocks with specs aren't aware of default
 arguments
In-Reply-To: <1498842809.59.0.716482523297.issue30821@psf.upfronthosting.co.za>
Message-ID: <1507726834.95.0.213398074469.issue30821@psf.upfronthosting.co.za>


Max Rothman <max.r.rothman at gmail.com> added the comment:

Hi, I'd like to wrap this ticket up and get some kind of resolution, whether it's accepted or not. I'm new to the Python community, what's the right way to prompt a discussion about this sort of thing? Should I have taken it to one of the mailing lists?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30821>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:01:38 2017
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Oct 2017 13:01:38 +0000
Subject: [issue31744] Python 2.7.14 Fails to compile on CentOS/RHEL7
In-Reply-To: <1507637861.45.0.213398074469.issue31744@psf.upfronthosting.co.za>
Message-ID: <1507726898.47.0.213398074469.issue31744@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31744>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:17:18 2017
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Oct 2017 13:17:18 +0000
Subject: [issue31751] Support for C++ 11 and/or C++ 14 in python.org installer
In-Reply-To: <1507661476.93.0.213398074469.issue31751@psf.upfronthosting.co.za>
Message-ID: <1507727838.17.0.213398074469.issue31751@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

No rush!  And I didn't mean to imply that how the macOS installers are built is perfect or updates shouldn't be considered.  But we should understand what the issue here is, independent of potential changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31751>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:22:30 2017
From: report at bugs.python.org (Louie Lu)
Date: Wed, 11 Oct 2017 13:22:30 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1507728150.89.0.213398074469.issue31752@psf.upfronthosting.co.za>


Louie Lu <me at louie.lu> added the comment:

I got a different result in latest commit: eeb5ffd54e5

?  cpython git:(master) ? ./python test.py
Traceback (most recent call last):
  File "test.py", line 15, in <module>
    timedelta(hours=BadInt(1))
SystemError: <class 'datetime.timedelta'> returned NULL without setting an error

Do I miss some configure, I'm using ./configure --with-debug

----------
nosy: +louielu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:24:32 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 13:24:32 +0000
Subject: [issue31490] assertion failure in ctypes in case an _anonymous_ attr
 appears outside _fields_
In-Reply-To: <1505555858.95.0.114491369101.issue31490@psf.upfronthosting.co.za>
Message-ID: <1507728272.63.0.213398074469.issue31490@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
pull_requests: +3927
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31490>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:29:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 13:29:14 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507728554.94.0.213398074469.issue31728@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f15058a697de12b0efe6c7ebc38fe61a993bb5d5 by Serhiy Storchaka (Oren Milman) in branch '2.7':
[2.7] bpo-31728: Prevent crashes in _elementtree due to unsafe cleanup of Element.text and Element.tail (GH-3924) (#3950)
https://github.com/python/cpython/commit/f15058a697de12b0efe6c7ebc38fe61a993bb5d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:29:16 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 13:29:16 +0000
Subject: [issue28157] Document time module constants (timezone, tzname,
 etc.) as deprecated.
In-Reply-To: <1473880626.53.0.480703935063.issue28157@psf.upfronthosting.co.za>
Message-ID: <1507728556.56.0.213398074469.issue28157@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 703ff381ffa946c23e7e25b0ae93a636a2607a40 by Berker Peksag (Cheryl Sabella) in branch 'master':
bpo-28157: Improvements for the time module documentation (GH-928)
https://github.com/python/cpython/commit/703ff381ffa946c23e7e25b0ae93a636a2607a40


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28157>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:30:34 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Oct 2017 13:30:34 +0000
Subject: [issue28157] Document time module constants (timezone, tzname,
 etc.) as deprecated.
In-Reply-To: <1473880626.53.0.480703935063.issue28157@psf.upfronthosting.co.za>
Message-ID: <1507728634.76.0.213398074469.issue28157@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +3928

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28157>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:37:36 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Oct 2017 13:37:36 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507729056.41.0.213398074469.issue31741@psf.upfronthosting.co.za>


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

Ah, so backports is a package on pypi.  You should report this problem wherever they do their bug tracking.  It is *possible* there is some problem in 2.7 on windows, but it is much more likely to be a bug in backports on windows.  In sort, python does not do *anything* special with a directory named backports; whatever is happening is a consequence of how that package (or one of the packages you have installed that installs into backports) interacts with the generic python import machinery.

Perhaps Paul will see something of interest here, though.

----------
resolution:  -> third party

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:44:11 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 13:44:11 +0000
Subject: [issue31728] crashes in _elementtree due to unsafe decrefs of
 Element.text and Element.tail
In-Reply-To: <1507493787.35.0.213398074469.issue31728@psf.upfronthosting.co.za>
Message-ID: <1507729451.73.0.213398074469.issue31728@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Oren!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31728>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:44:50 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 13:44:50 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507729490.4.0.213398074469.issue28647@psf.upfronthosting.co.za>


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


----------
pull_requests: +3929

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:47:28 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 11 Oct 2017 13:47:28 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1507729648.76.0.213398074469.issue31756@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:49:30 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 13:49:30 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507729769.99.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Pull request for issue 30404 has been merged so we only need the documentation patch for the 3.6 branch (unfortunately 3.5 is now in security-fix-only mode) I've opened PR 3954.

----------
versions:  -Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:50:24 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 13:50:24 +0000
Subject: [issue28157] Document time module constants (timezone, tzname,
 etc.) as deprecated.
In-Reply-To: <1473880626.53.0.480703935063.issue28157@psf.upfronthosting.co.za>
Message-ID: <1507729824.15.0.213398074469.issue28157@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 764969a4b9ed7c6d2adbc04269f9b4fa392a1eed by Berker Peksag (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-28157: Improvements for the time module documentation (GH-928)
https://github.com/python/cpython/commit/764969a4b9ed7c6d2adbc04269f9b4fa392a1eed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28157>
_______________________________________

From report at bugs.python.org  Wed Oct 11 09:51:47 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 13:51:47 +0000
Subject: [issue28157] Document time module constants (timezone, tzname,
 etc.) as deprecated.
In-Reply-To: <1473880626.53.0.480703935063.issue28157@psf.upfronthosting.co.za>
Message-ID: <1507729907.2.0.213398074469.issue28157@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

This issue can be closed now. Thank you, everyone!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28157>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:10:05 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 14:10:05 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507731005.65.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 5f908005ce16b06d5af7b413264009c4b062f33c by Berker Peksag in branch '3.6':
bpo-28647: Update -u documentation (GH-3954)
https://github.com/python/cpython/commit/5f908005ce16b06d5af7b413264009c4b062f33c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:10:39 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 14:10:39 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507731039.5.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the patch, Gareth.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:29:50 2017
From: report at bugs.python.org (Gareth Rees)
Date: Wed, 11 Oct 2017 14:29:50 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507732190.82.0.213398074469.issue28647@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

You're welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:30:51 2017
From: report at bugs.python.org (Paul Moore)
Date: Wed, 11 Oct 2017 14:30:51 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507732251.15.0.213398074469.issue31741@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

My feeling is still that it's an issue with things (i.e., imports) happening before you adjust sys.path. But without seeing actual code that reproduces the issue, there's no way of being sure. And if that is what's going on, it wouldn't be an issue with core Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:31:07 2017
From: report at bugs.python.org (Aaron Hall)
Date: Wed, 11 Oct 2017 14:31:07 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1507732267.66.0.213398074469.issue31753@psf.upfronthosting.co.za>


Aaron Hall <aaronchall at yahoo.com> added the comment:

So... moving the closure (which may be called recursively) to the global scope actually does improve performance (for small cases, about 10% - larger cases amortize the cost of the closure being built, but in a 100 item dictionary, still about 4% faster to extricate the closure). So I'm reopening. Also suggesting we consider doing this with other functions if they are unnecessarily closures in the module.

`fix_missing_locations` appears to be another such function with an unnecessary closure.

the closure in `dump` cannot be removed without some rewriting of the signature, as it uses variables it closes over. Not sure this would be worth it.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:40:19 2017
From: report at bugs.python.org (Heinrich Schnermann)
Date: Wed, 11 Oct 2017 14:40:19 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
Message-ID: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>


New submission from Heinrich Schnermann <pythonbug at schnermann.net>:

In https://docs.python.org/3/tutorial/controlflow.html#defining-functions both examples produce fibonacci numbers starting with 0. They should start with 1, as in the example in https://docs.python.org/3/tutorial/introduction.html#first-steps-towards-programming

The first example should change the lines
    while a < n:
        print(a, end=' ')
to
    while b < n:
        print(b, end=' ')

and the second example should change the lines
    while a < n:
        result.append(a)    # see below
to
    while b < n:
        result.append(b)    # see below

----------
assignee: docs at python
components: Documentation
messages: 304144
nosy: docs at python, skyhein
priority: normal
severity: normal
status: open
title: Tutorial: Fibonacci numbers start with 1, 1
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:46:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Oct 2017 14:46:48 +0000
Subject: [issue23532] add example of 'first match wins' to regex "|"
 documentation?
In-Reply-To: <1424991623.26.0.907615110662.issue23532@psf.upfronthosting.co.za>
Message-ID: <1507733208.62.0.213398074469.issue23532@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23532>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:51:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Oct 2017 14:51:27 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507733487.48.0.213398074469.issue31415@psf.upfronthosting.co.za>


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


----------
pull_requests: +3930

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:53:39 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 14:53:39 +0000
Subject: [issue31758] various refleaks in _elementtree
Message-ID: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code results in refleaks:
import sys
import _elementtree
builder = _elementtree.TreeBuilder()
parser = _elementtree.XMLParser(target=builder)

refcount_before = sys.gettotalrefcount()
parser.__init__(target=builder)
print(sys.gettotalrefcount() - refcount_before)  # should be close to 0

This is because _elementtree_XMLParser___init___impl()
(in Modules/_elementtree.c) doesn't decref before assigning to fields of
`self`.


The following code also results in refleaks:
import sys
import _elementtree
elem = _elementtree.Element(42)
elem.__setstate__({'tag': 42, '_children': list(range(1000))})

refcount_before = sys.gettotalrefcount()
elem.__setstate__({'tag': 42, '_children': []})
print(sys.gettotalrefcount() - refcount_before)  # should be close to -1000

This is because element_setstate_from_attributes() doesn't decref the old
children before storing the new children.


I would open a PR to fix this soon.

----------
components: XML
messages: 304145
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: various refleaks in _elementtree
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Wed Oct 11 10:56:13 2017
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Riel?=)
Date: Wed, 11 Oct 2017 14:56:13 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
Message-ID: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>


New submission from Rapha?l Riel <raphael.riel at gmail.com>:

re won't raise nor return when working with Runaway Regular Expression.
It will compute "almost" indefinitely. Although I'm pretty sure it *may* complete sometime, it's definetly looks like it's stuck.

```
> python -VVVV
Python 3.6.2 (default, Aug 23 2017, 14:57:08)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
```

Reproduce with attached file.

Should there be a (configurable?) limit on the number of steps involved in the process.
Or some warnings and/or hard limit that raises exception?

https://pythex.org/ will fail with a HTTP502 BadGateway (server taking too long to respond)
https://regex101.com/ python's tester seems to set a limit for this case. I can't say how they managed this.

----------
components: Regular Expressions
files: re_backtracking.py
messages: 304146
nosy: Rapha?l Riel, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re wont recover nor fail on runaway regular expression
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47212/re_backtracking.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:08:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Oct 2017 15:08:54 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507734534.72.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

I just checked the master branch:

-u     : unbuffered binary stdout and stderr, stdin always buffered;
         also PYTHONUNBUFFERED=x
         see man page for details on internal buffering relating to '-u'

The doc is wrong. stdout and stderr are fully unbuferred since Serhiy changed them: commit 77732be801c18013cfbc86e27fcc50194ca22c8e, bpo-30404.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:14:45 2017
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 11 Oct 2017 15:14:45 +0000
Subject: [issue31760] Re-definition of _POSIX_C_SOURCE with Fedora 26.
Message-ID: <1507734885.66.0.213398074469.issue31760@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

Hi all,

Is it problematic ? if it is not the case, we can close it.


In file included from /home/stephane/src/github.com/python/cpython/Modules/expat/expat_config.h:8:0,
                 from /home/stephane/src/github.com/python/cpython/Modules/expat/xmltok.c:41:
./pyconfig.h:1457:0: warning: "_POSIX_C_SOURCE" redefined
 #define _POSIX_C_SOURCE 200809L
 
In file included from /usr/include/bits/libc-header-start.h:33:0,
                 from /usr/include/string.h:26,
                 from /home/stephane/src/github.com/python/cpython/Modules/expat/xmltok.c:35:
/usr/include/features.h:286:0: note: this is the location of the previous definition
 # define _POSIX_C_SOURCE 199506L


St?phane

----------
messages: 304148
nosy: matrixise
priority: normal
severity: normal
status: open
title: Re-definition of _POSIX_C_SOURCE with Fedora 26.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31760>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:23:39 2017
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Oct 2017 15:23:39 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1507735419.23.0.213398074469.issue31756@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Really, this is just an alias for universal_newlines in Popen.__init__. So we add the parameter and:

+    if text:
+        universal_newlines = True
     self.universal_newlines = universal_newlines

And 99% of the change is making it clear in the docs why we have two arguments with the same meaning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:25:45 2017
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Oct 2017 15:25:45 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1507735545.36.0.213398074469.issue31756@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

> just an alias

Which I recognise is in the bug title. My point is that the enhancement itself is less relevant than the rationale and the documentation. 

Without a doc patch, there's really nothing to discuss here other than duplicating APIs (which is probably justified, even though it looks like a wart).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:39:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 15:39:21 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507736361.78.0.213398074469.issue31415@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Why global _PyTime_GetWinPerfCounterWithInfo() is needed at all? It seems to me that _PyTime_GetPerfCounterWithInfo() can be used instead. Smaller API is better.

_PyTime_GetPerfCounter() is a simple wrapper around _PyTime_GetPerfCounterWithInfo() and is used only in one place. Getting rid of it will simplify C API too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:39:49 2017
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 11 Oct 2017 15:39:49 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507736389.1.0.213398074469.issue31327@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Steve, I have added you on this issue because it's related to Windows.

Maybe you could check it.

----------
nosy: +matrixise, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:40:56 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Oct 2017 15:40:56 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507736456.39.0.213398074469.issue31415@psf.upfronthosting.co.za>


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

> Why global _PyTime_GetWinPerfCounterWithInfo() is needed at all? It seems to me that _PyTime_GetPerfCounterWithInfo() can be used instead. Smaller API is better.

I chose to expose _PyTime_GetWinPerfCounterWithInfo() to make my change as small as possible.

I didn't want to break the old time.clock() clock by mistake.

By the way, time.clock() is deprecated since Python 3.3. It's maybe time to drop it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:48:49 2017
From: report at bugs.python.org (Tim Peters)
Date: Wed, 11 Oct 2017 15:48:49 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507736929.68.0.213398074469.issue31327@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

The docs for the `time` module say:

"""
Although this module is always available, not all functions are available on all platforms. Most of the functions defined in this module call platform C library functions with the same name. It may sometimes be helpful to consult the platform documentation, because the semantics of these functions varies among platforms.
"""

The Windows `localtime()` simply doesn't support dates before the epoch:

https://msdn.microsoft.com/en-us/library/aa246456(v=vs.60).aspx

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 11:55:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 15:55:40 +0000
Subject: [issue31758] various refleaks in _elementtree
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1507737340.09.0.213398074469.issue31758@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka
stage:  -> needs patch
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:00:50 2017
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 11 Oct 2017 16:00:50 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507737650.95.0.213398074469.issue31327@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Thank you Tim,

In this case, the documentation seems to be correct, maybe we could close this issue because it's independent of Python.

What's your opinion on this point?

Close it or Improve the documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:07:56 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Oct 2017 16:07:56 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507738076.46.0.213398074469.issue31757@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is there any particular reason you want to start with 1? While not universal, it's standard to define `Fib(0) = 0`, and to start the sequence at `0`. (And note that Python usually starts indexing things from 0, so it makes sense to start with `Fib(0)` rather than `Fib(1)`.)

In principle, one could define `Fib(0)=1`, `Fib(1)=1`, `Fib(1)=2`, and so on, but there's a strong reason not to do so: it breaks (or at least uglifies) many nice number-theoretic properties, like `gcd(Fib(m), Fib(n)) == Fib(gcd(m, n))`.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:14:21 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Oct 2017 16:14:21 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507738461.72.0.213398074469.issue31757@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A nice response to the question of whether to start with 0 or 1 here: https://stackoverflow.com/a/5901955

> The definition with Fib(0) = 1 is known as the combinatorial
> definition, and Fib(0) = 0 is the classical definition. Both
> are used in the Fibonacci Quarterly, though authors that use
> the combinatorial definition need to add a sentence of
> explanation.

I confess that I hadn't heard of the Fibonacci Quarterly before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:22:08 2017
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 11 Oct 2017 16:22:08 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1507738928.07.0.213398074469.issue31756@psf.upfronthosting.co.za>


Andrew Clegg <andrew.clegg at durham.ac.uk> added the comment:

OK great, I'll get working on a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:22:20 2017
From: report at bugs.python.org (Tim Peters)
Date: Wed, 11 Oct 2017 16:22:20 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507738940.53.0.213398074469.issue31327@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Since this is a pretty common gotcha, I'd prefer to add it as an example to the text I already quoted; e.g., add:

"""
For example, the native Windows C libraries do not support times before the epoch, and `localtime(n)` for negative `n` raises `OSError` on Windows.
"""

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
type: crash -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:24:17 2017
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 11 Oct 2017 16:24:17 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507739057.19.0.213398074469.issue31327@psf.upfronthosting.co.za>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Thank you, I will provide a PR for this issue and close it once it's over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:33:41 2017
From: report at bugs.python.org (Tim Peters)
Date: Wed, 11 Oct 2017 16:33:41 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507739621.37.0.213398074469.issue31327@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

I'll just add that it may be a different issue to argue about how `_naive_is_dst()` is implemented.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:52:47 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 11 Oct 2017 16:52:47 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1507740767.66.0.213398074469.issue31327@psf.upfronthosting.co.za>


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

Is this similar to issue 29097?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Oct 11 12:55:04 2017
From: report at bugs.python.org (Denis Osipov)
Date: Wed, 11 Oct 2017 16:55:04 +0000
Subject: [issue31761] Possible error in devguide part about tests
Message-ID: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>


New submission from Denis Osipov <osipov_d at list.ru>:

In Developer Guide says:

"If you don?t have easy access to a command line, you can run the test suite from a Python or IDLE shell:

>>> from test import autotest"

But I can't run test from IDLE:

Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    from test import autotest
  File "D:\repos\cpython\Lib\test\autotest.py", line 5, in <module>
    main()
  File "D:\repos\cpython\Lib\test\libregrtest\main.py", line 585, in main
    Regrtest().main(tests=tests, **kwargs)
  File "D:\repos\cpython\Lib\test\libregrtest\main.py", line 510, in main
    self._main(tests, kwargs)
  File "D:\repos\cpython\Lib\test\libregrtest\main.py", line 524, in _main
    setup_tests(self.ns)
  File "D:\repos\cpython\Lib\test\libregrtest\setup.py", line 18, in setup_tests
    faulthandler.enable(all_threads=True)
io.UnsupportedOperation: fileno

If I understand it correct, this behavior is reasonable (issues 3003 and 25588).
Maybe it's worth to remove words about running from IDLE. Or in case if it's possible to run such tests add some words about it.

----------
assignee: docs at python
components: Documentation
messages: 304163
nosy: denis-osipov, docs at python
priority: normal
severity: normal
status: open
title: Possible error in devguide part about tests
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Wed Oct 11 13:00:59 2017
From: report at bugs.python.org (Nikhil)
Date: Wed, 11 Oct 2017 17:00:59 +0000
Subject: [issue31762] Issue in login
In-Reply-To: <CACv8_d_Kz+2PMFyTJTgKq6z1sp+hEod=P3Kmy+jXQqMVu8=peQ@mail.gmail.com>
Message-ID: <CACv8_d9FLG+aUprB9-FLB55YnGGN8zxXan+qqi2nPbXmpjSzLw@mail.gmail.com>


New submission from Nikhil <nkhl681 at gmail.com>:

I have included the screen shot

----------
files: Screenshot_20171011_222848.png
messages: 304164
nosy: Nik101
priority: normal
severity: normal
status: open
title: Issue in login
Added file: https://bugs.python.org/file47213/Screenshot_20171011_222848.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31762>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20171011_222848.png
Type: image/png
Size: 22194 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20171011/e70d6e0c/attachment-0001.png>

From report at bugs.python.org  Wed Oct 11 13:05:26 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 17:05:26 +0000
Subject: [issue31758] various refleaks in _elementtree
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1507741526.24.0.213398074469.issue31758@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3931
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Wed Oct 11 13:14:49 2017
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Riel?=)
Date: Wed, 11 Oct 2017 17:14:49 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
In-Reply-To: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>
Message-ID: <1507742089.28.0.213398074469.issue31759@psf.upfronthosting.co.za>


Rapha?l Riel <raphael.riel at gmail.com> added the comment:

Results for my local computer:

```
Attempting test_01
Done in 0.12ms
Attempting test_02
Done in 1.52ms
Attempting test_03
Done in 26.24ms
Attempting test_04
Done in 432.32ms
Attempting test_05
Done in 886.3ms
Attempting test_06
Done in 1757.07ms
Attempting test_07
Done in 3388.92ms
Attempting test_08
Done in 6669.02ms
Attempting test_09
Done in 13088.37ms
Attempting test_10
Done in 26600.23ms
Attempting test_11
Done in 6722.9ms
Attempting test_12
Done in 211192.82ms
Attempting test_13
Done in 6850465.09ms
Attempting test_14
^CTraceback (most recent call last):
  File "/Users/rriel/Desktop/re_backtracking.py", line 26, in <module>
    bad_expression.sub("IN_GROUP", statement)
KeyboardInterrupt
```

Cancelled test_14...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Wed Oct 11 13:18:50 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Oct 2017 17:18:50 +0000
Subject: [issue31761] Possible error in devguide part about tests
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507742330.21.0.213398074469.issue31761@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Wed Oct 11 13:32:01 2017
From: report at bugs.python.org (Jonathan)
Date: Wed, 11 Oct 2017 17:32:01 +0000
Subject: [issue31727] FTP_TLS errors when
In-Reply-To: <1507482521.5.0.213398074469.issue31727@psf.upfronthosting.co.za>
Message-ID: <1507743121.5.0.213398074469.issue31727@psf.upfronthosting.co.za>


Jonathan <bugreports at lightpear.com> added the comment:

Just tested this with Python 3.7.0a1. I'm afraid it makes no difference. Exact same error:

*cmd* 'LIST'
*put* 'LIST\r\n'
*get* '150 Accepted data connection\n'
*resp* '150 Accepted data connection'
Traceback (most recent call last):
  File "c:\backup_script.py", line 385, in run_ftps
    ftps.dir()
  File "c:\Python37\lib\ftplib.py", line 575, in dir
    self.retrlines(cmd, func)
  File "c:\Python37\lib\ftplib.py", line 485, in retrlines
    conn.unwrap()
  File "c:\Python37\lib\ssl.py", line 1059, in unwrap
    s = self._sslobj.unwrap()
  File "c:\Python37\lib\ssl.py", line 706, in unwrap
    return self._sslobj.shutdown()
OSError: [Errno 0] Error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31727>
_______________________________________

From report at bugs.python.org  Wed Oct 11 14:00:28 2017
From: report at bugs.python.org (Heinrich Schnermann)
Date: Wed, 11 Oct 2017 18:00:28 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507744828.32.0.213398074469.issue31757@psf.upfronthosting.co.za>


Heinrich Schnermann <pythonbug at schnermann.net> added the comment:

I would not insist of starting with 1 instead of 0 (I follow your arguments here), but perhaps it would be nice if it would behave the same way in both chapters. The first fibonacci number examples in https://docs.python.org/3/tutorial/introduction.html#first-steps-towards-programming start with 1.

There are three examples here, in the first,

while b < 10:
    print(b)

should change to

while a < 10:
    print(a)

The output of this first example would have an additional 0:
0
1
1
...

And in the third example

while b < 1000:
    print(b, end=',')

should change to

while a < 1000:
    print(a, end=',')

where the output of this third example would change from

1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,

to

0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Wed Oct 11 14:48:25 2017
From: report at bugs.python.org (Matthew Patton)
Date: Wed, 11 Oct 2017 18:48:25 +0000
Subject: [issue31763] Add TRACE level to the logging module
Message-ID: <1507747705.55.0.213398074469.issue31763@psf.upfronthosting.co.za>


New submission from Matthew Patton <pattonme at yahoo.com>:

This was inspired by 31732.
The logging module has 5 log levels: CRITICAL, ERROR, WARNING, INFO, DEBUG per https://docs.python.org/dev/library/logging.html#logging-levels

However syslog(3) has for decades defined NOTICE and I can't think of a good reason why this level was carried through. It serves a very useful distinction from routine and not really attention-worthy messages (INFO) but don't rise to actual WARNINGs. Things like failed authentication attempts are not warnings but also not messages to casually ignore. Hence NOTICE. Individual timed out connection attempts but before all attempts exhausted, and many other examples exist.

----------
components: Library (Lib)
messages: 304168
nosy: mp5023
priority: normal
severity: normal
status: open
title: Add TRACE level to the logging module
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31763>
_______________________________________

From report at bugs.python.org  Wed Oct 11 14:48:56 2017
From: report at bugs.python.org (Tim Peters)
Date: Wed, 11 Oct 2017 18:48:56 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
In-Reply-To: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>
Message-ID: <1507747736.37.0.213398074469.issue31759@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Well, the problem in the regexp is this part:  "\d+,? ?".  You're not _requiring_ that strings of digits be separated by a comma or blank, you're only _allowing_ them to be so separated.  A solid string of digits is matched by this, and so the enclosing + requires the engine, when backtracking, to consider every possible way of breaking the solid string of digits into one or more solid strings of digits too.  If there are n digits in the digit string, there are 2**(n-1) ways to do so.

Overall the regexp can never match because "NULL" never gets matched.  So all possibilities will be tried.  We can compute how many attempts will be made like so:

    prod = 1
    for c in re.findall("\d+|NULL", statement):
        if c == "NULL":
            break
        prod *= 2**(len(c) - 1)
    print(format(prod, ","))


Attempting test_01
256
Attempting test_02
4,096
Attempting test_03
65,536
Attempting test_04
1,048,576
Attempting test_05
2,097,152
Attempting test_06
4,194,304
Attempting test_07
8,388,608
Attempting test_08
16,777,216
Attempting test_09
33,554,432
Attempting test_10
67,108,864
Attempting test_11
16,777,216
Attempting test_12
536,870,912
Attempting test_13
17,179,869,184
Attempting test_14
549,755,813,888

Note, e.g., this "predicts" test_08 will take about the same time as test_11 (both require 16,777,216 attempts).  Which is what you actually saw happen.

And that's why you gave up on test_14:  it will require over half a trillion failing attempts before it ends, which will take roughly 30 times longer than it failed to match test_13.

If we were building a regexp _tester_, we'd spin off a new process to run the regexp, and kill the process if it took "too long".  But that's not we're doing - library functions do what you tell them to do ;-)

In this case, it's easily repaired.  For example, replace

    "\d+,? ?"

 by 

    "\d+(?=[ ,)]),? ?"

This uses a lookahead assertion to _require_ that a digit string is followed by a blank, comma, or right parenthesis.  Which prevents exponential-time backtracking in failing cases.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Wed Oct 11 14:49:37 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Oct 2017 18:49:37 +0000
Subject: [issue31762] Issue in login
In-Reply-To: <CACv8_d9FLG+aUprB9-FLB55YnGGN8zxXan+qqi2nPbXmpjSzLw@mail.gmail.com>
Message-ID: <1507747777.55.0.213398074469.issue31762@psf.upfronthosting.co.za>


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

This tracker is for reporting bugs in python.  If you want to report a problem with the tracker, please use the 'report tracker problem' link in the left column.  (That said, I thought the error message you show in the screenshot was fixed by the recent tracker upgrade, but then again the screenshot doesn't look like any image of the tracker I've ever seen.  So if you open a tracker error report please provide additional information about your environment and what actions will reproduce the error).

----------
nosy: +r.david.murray
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31762>
_______________________________________

From report at bugs.python.org  Wed Oct 11 14:53:09 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Oct 2017 18:53:09 +0000
Subject: [issue31763] Add NOTICE level to the logging module
In-Reply-To: <1507747705.55.0.213398074469.issue31763@psf.upfronthosting.co.za>
Message-ID: <1507747989.57.0.213398074469.issue31763@psf.upfronthosting.co.za>


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

I fixed the title for you, otherwise this looks like a duplicate of issue 31732.

----------
nosy: +r.david.murray
title: Add TRACE level to the logging module -> Add NOTICE level to the logging module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31763>
_______________________________________

From report at bugs.python.org  Wed Oct 11 14:54:54 2017
From: report at bugs.python.org (Matthew Patton)
Date: Wed, 11 Oct 2017 18:54:54 +0000
Subject: [issue31763] Add NOTICE level to the logging module
In-Reply-To: <1507747705.55.0.213398074469.issue31763@psf.upfronthosting.co.za>
Message-ID: <1507748094.54.0.213398074469.issue31763@psf.upfronthosting.co.za>


Change by Matthew Patton <pattonme at yahoo.com>:


----------
keywords: +patch
pull_requests: +3932
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31763>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:01:34 2017
From: report at bugs.python.org (Matthew Patton)
Date: Wed, 11 Oct 2017 19:01:34 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507748494.68.0.213398074469.issue30767@psf.upfronthosting.co.za>


Change by Matthew Patton <pattonme at yahoo.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:03:04 2017
From: report at bugs.python.org (Matthew Patton)
Date: Wed, 11 Oct 2017 19:03:04 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507748584.38.0.213398074469.issue30767@psf.upfronthosting.co.za>


Change by Matthew Patton <pattonme at yahoo.com>:


----------
nosy: +mp5023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:09:18 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 19:09:18 +0000
Subject: [issue31764] sqlite3.Cursor.close() crashes in case the Cursor object
 is uninitialized
Message-ID: <1507748958.42.0.213398074469.issue31764@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes a crash:
import sqlite3
cursor = sqlite3.Cursor.__new__(sqlite3.Cursor)
cursor.close()

this is because pysqlite_cursor_close() (in Modules/_sqlite/cursor.c) assumes
that `self->connection` is not NULL, and passes it to pysqlite_check_thread(),
which crashes.


I would open a PR to fix this soon.

----------
components: Extension Modules
messages: 304172
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: sqlite3.Cursor.close() crashes in case the Cursor object is uninitialized
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31764>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:10:07 2017
From: report at bugs.python.org (Nikhil)
Date: Wed, 11 Oct 2017 19:10:07 +0000
Subject: [issue31765] BUG: System deadlocks performing big loop operations in
 python 3.5.4, windows 10
In-Reply-To: <CACv8_d-MGZ2r3eRwoTPZvFAB-1ZS4xFcPNm2Kd44tzkC3EgvFQ@mail.gmail.com>
Message-ID: <CACv8_d82W8AYy961pnw8S-3pu3YHmsNfcp_5YW2y+43hPYUK0g@mail.gmail.com>


New submission from Nikhil <nkhl681 at gmail.com>:

What I did
1) root file declared where operation will start and import hashlib for
getting hash signatures
2) os.walk for recursively diving into directory tree
3) open file and find sha256 digest and print it
4) close the file
5) recursively repeat all above 2 steps till we traversed directory tree

Above logic python program caused sudden exponential increase in RAM usage
(task manager by chance)  and certainly DEADLOCK and......  Force shutdown

I want to know what went wrong.....

----------
messages: 304173
nosy: Nik101
priority: normal
severity: normal
status: open
title: BUG: System deadlocks performing big loop operations in python 3.5.4, windows 10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31765>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:18:19 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Oct 2017 19:18:19 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507749499.42.0.213398074469.issue31757@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree it would be good to be consistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:20:34 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Oct 2017 19:20:34 +0000
Subject: [issue31765] BUG: System deadlocks performing big loop operations in
 python 3.5.4, windows 10
In-Reply-To: <CACv8_d82W8AYy961pnw8S-3pu3YHmsNfcp_5YW2y+43hPYUK0g@mail.gmail.com>
Message-ID: <1507749634.75.0.213398074469.issue31765@psf.upfronthosting.co.za>


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

Most likely an error in your program logic, I'm afraid.  This isn't a forum for getting help, you should try the python-list mailing list.  (If you do find a bug, you can then open an issue with details.)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31765>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:40:28 2017
From: report at bugs.python.org (Zekun Li)
Date: Wed, 11 Oct 2017 19:40:28 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507750828.34.0.213398074469.issue31558@psf.upfronthosting.co.za>


Zekun Li <li.zekun at gmail.com> added the comment:

> This is only useful if the parent process has a lot of memory that's never used by the child processes right? Otherwise, you would lose via refcounting COWs.

What we saw in prod is that memory fragmentation caused by gc is the main reason of shared memory shrink.

The memory fragmentation is figured out by doing a full collection before fork and keep it disabled, it'll make a bunch of copy-on-write in child process.

This can't solve the copy-on-write caused by ref count, but we're thinking about freezing the ref count on those permanent objects too.

So this is useful if you did some warm-up work in parent process.

Also it could speedup gc if you have large amount of permanent objects.

----------
nosy: +brainfvck

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:41:54 2017
From: report at bugs.python.org (Oren Milman)
Date: Wed, 11 Oct 2017 19:41:54 +0000
Subject: [issue31764] sqlite3.Cursor.close() crashes in case the Cursor object
 is uninitialized
In-Reply-To: <1507748958.42.0.213398074469.issue31764@psf.upfronthosting.co.za>
Message-ID: <1507750914.48.0.213398074469.issue31764@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3934
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31764>
_______________________________________

From report at bugs.python.org  Wed Oct 11 15:49:25 2017
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Riel?=)
Date: Wed, 11 Oct 2017 19:49:25 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
In-Reply-To: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>
Message-ID: <1507751365.23.0.213398074469.issue31759@psf.upfronthosting.co.za>


Rapha?l Riel <raphael.riel at gmail.com> added the comment:

Thanks Tim! Pretty nice answer that I can learn from! Thanks for your time.

I definitely knew my Regex was broken, yet I was surprised the interpreter/library didn't gave up/error after some(several million) steps.

Some other language seems to just assume there will be no match (Source: some play on https://regex101.com/), and I don't think this is a valid approach.

Should there be a WARNing logged on a defined soft-limit?

I know this is low-level "re" library, and your point is pretty valid about the fact the lib should be doing what it's told to do. 
I was mostly looking for opinion about WARNs on soft limits and maybe errors on a hard-limit to debug/avoid this kind of false-hang situation.

Feel free to close/wont-fix/not-a-bug this issue! And thanks again for your kind answer to my initial issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Wed Oct 11 16:01:01 2017
From: report at bugs.python.org (Jason Stelzer)
Date: Wed, 11 Oct 2017 20:01:01 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507752061.6.0.213398074469.issue31749@psf.upfronthosting.co.za>


Jason Stelzer <jason.stelzer at gmail.com> added the comment:

Just pointing out that this exists and seems active.

https://github.com/tbielawa/bitmath

Perhaps include some or all of it in core python? Crazier things have happened.

----------
nosy: +Jason Stelzer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Wed Oct 11 16:21:52 2017
From: report at bugs.python.org (Rich)
Date: Wed, 11 Oct 2017 20:21:52 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507753312.63.0.213398074469.issue31749@psf.upfronthosting.co.za>


Rich <miserlou+python2 at gmail.com> added the comment:

I think bitmath would be overkill to include in its entirety, but maybe there solution is a good one.

There is also:

https://pypi.python.org/pypi/byteformat/
https://pypi.python.org/pypi/datasize
https://pypi.python.org/pypi/hurry.filesize
https://pypi.python.org/pypi/hfilesize/
https://humanfriendly.readthedocs.io/en/latest/
https://pypi.python.org/pypi/humanize

and a bajillion other solutions here: https://stackoverflow.com/questions/1094841/reusable-library-to-get-human-readable-version-of-file-size and elsewhere - I think really the underscoring how common this problem is.

(Although I don't _particularly want_ this to expand beyond the scope of this single function, it does seem that given the amount of "Python for Humans" stuff out there, there could be an argument made for adding a "humanize" package into the standard library..)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Wed Oct 11 16:30:48 2017
From: report at bugs.python.org (Jason Stelzer)
Date: Wed, 11 Oct 2017 20:30:48 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1507753848.35.0.213398074469.issue31749@psf.upfronthosting.co.za>


Jason Stelzer <jason.stelzer at gmail.com> added the comment:

I often speak in generalizations and half thoughts. Feel free to cherry pick as much or a little as you want.

Including a core shim of whatever is agreed to be the minimalist functionality with a SEE ALSO note or clue as to where to start would:

* Resolve the basic out-of-the-box stuff.

* Eliminate a lot of boring DIY stuff for people who reach for an editor first and search second.

* Give new users much firmer footing.

* Give some everything and the kitchen sink projects wider exposure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:18:37 2017
From: report at bugs.python.org (Anthony Flury)
Date: Wed, 11 Oct 2017 21:18:37 +0000
Subject: [issue31766] Python 3.5 missing from documentation
Message-ID: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>


New submission from Anthony Flury <anthony.flury at btinternet.com>:

In the Python version pull down list on docs.python.org, Python3.5 used to be listed, but has now been removed; the list only contains 2.7, 3.6 & 3.7.

Python 3.5 is still the official Python 3.5 release in the Ubuntu repository, and still a supported release in other parts of python.org, so to see it disappearing from the drop-down was surprising.

To note - if you pick a particular page - say : 

https://docs.python.org/3/tutorial/index.html

and change the url to : 

https://docs.python.org/3.5/tutorial/index.html

The pull down now does contain 3.5 (along side 2.7, 3.63 & 3.7)

----------
assignee: docs at python
components: Documentation
messages: 304181
nosy: anthony-flury, docs at python
priority: normal
severity: normal
status: open
title: Python 3.5 missing from documentation
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:23:15 2017
From: report at bugs.python.org (Igor Skochinsky)
Date: Wed, 11 Oct 2017 21:23:15 +0000
Subject: [issue31767] Windows Installer fails with error 0x80091007 when
 trying to install debugging symbols
Message-ID: <1507756995.05.0.213398074469.issue31767@psf.upfronthosting.co.za>


New submission from Igor Skochinsky <skochinsky at gmail.com>:

Trying to install 3.6.3 on Windows 10 and getting this error.

Repro steps:

1. Download python-3.6.3.exe or python-3.6.3-amd64.exe, run it
2. Select "Customize Installation"
3. Next
4. In Advanced Options, select 
[x] Install for all users (not sure if important)
[x] Download debugging symbols
change path to F:\Python36 (not sure if it matters but my system drive is F: and C: is missing except for when I plug in a USB drive)
Ucheck
[ ] Associate files with Python
Click Install and accept elevation prompt. After a while it fails with 

Error 0x80091007 - Hash value not correct.

Interestingly, "log file" link does not work. I had to go hunt for the log in %temp% myself. The relevant parts:

Error 0x80091007: Hash mismatch for path: F:\ProgramData\Package Cache\.unverified\core_AllUsers_pdb, expected: A4B6E4A818E49F000513774F034EC98A194E3C3D, actual: 36C7B852E586D26F4D239ED72EFE5FFBEBA21825
Error 0x80091007: Failed to verify hash of payload: core_AllUsers_pdb
Failed to verify payload: core_AllUsers_pdb at path: F:\ProgramData\Package Cache\.unverified\core_AllUsers_pdb, error: 0x80091007. Deleting file.
Application requested retry of payload: core_AllUsers_pdb, encountered error: 0x80091007. Retrying...

There are a few more retries basically with the same result. However, this one is interesting:

Acquiring package: core_AllUsers_pdb, payload: core_AllUsers_pdb, copy from: F:\Users\Igor\Downloads\core_pdb.msi

I don't have such a file there, just the installer .exe

----------
components: Installation
messages: 304182
nosy: Igor.Skochinsky
priority: normal
severity: normal
status: open
title: Windows Installer fails with error 0x80091007 when trying to install debugging symbols
type: security
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31767>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:32:31 2017
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 11 Oct 2017 21:32:31 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
In-Reply-To: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>
Message-ID: <1507757551.8.0.213398074469.issue31759@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

You shouldn't assume that just because it takes a long time on one implementation that it'll take a long time on all of the others, because it's sometimes possible to include additional checks to reduce the problem. (I doubt you could eliminate the problem entirely, however.)

My regex module, for example, includes some additional checks, and it seems to be OK with these tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:48:13 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 11 Oct 2017 21:48:13 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507758493.58.0.213398074469.issue30744@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:49:25 2017
From: report at bugs.python.org (caveman)
Date: Wed, 11 Oct 2017 21:49:25 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
Message-ID: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>


New submission from caveman <toraboracaveman at gmail.com>:

if you execute the code below, mutually exclusive agrs are separated by '|' as expected. but if you uncomment the 1 line down there, then the args list will be too long, and as argparse tries to wrap the args around, it drops all '|'s which semantically destroys the intended syntax of the arguments.

import argparse

parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group()
group.add_argument("-v", "--verbose", action="store_true")
group.add_argument("-q", "--quiet", action="store_true")
group.add_argument("-x", metavar='X', type=str, help="the base", nargs='?')
group.add_argument("-y", metavar='Y', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
#group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')

args = parser.parse_args()

----------
components: Library (Lib)
messages: 304184
nosy: caveman
priority: normal
severity: normal
status: open
title: argparse drops '|'s when the arguments are too long
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:55:25 2017
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Oct 2017 21:55:25 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507758925.38.0.213398074469.issue31766@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

The documentation for 3.5 was deliberated removed from the pull down lists of current docsets as 3.5 is now in security-fix-only mode; the 3.5 documentation is only updated when a new security release is made and general doc changes to it are no longer made.  You can find a link to the docsets for 3.5.x and all Python releases on the Python Documentation By Version page (https://www.python.org/doc/versions/) which is linked to from a number of places, including the index page of the current and past Python versions docsets (e.g. https://docs.python.org/3/) and from the main python.org doc page (https://www.python.org/doc/).

----------
nosy: +larry, ned.deily
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Wed Oct 11 17:59:40 2017
From: report at bugs.python.org (caveman)
Date: Wed, 11 Oct 2017 21:59:40 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507759180.01.0.213398074469.issue31768@psf.upfronthosting.co.za>


caveman <toraboracaveman at gmail.com> added the comment:

forgot to add: when you execute the code, pass the argument '-h' in order to have the script generate the help menu text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Wed Oct 11 18:32:34 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 11 Oct 2017 22:32:34 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507761154.79.0.213398074469.issue31768@psf.upfronthosting.co.za>


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

Removing versions 3.4 and 3.8.

Attaching a reproducing script.  Run it with a parameter of the number of arguments to add. The behavior changes between 7 and 8, although I'm not sure either is wrong, just different. This is from Windows:

% python3 31768.py 7
usage: 31768.py [-h] [-v | -q | -x [X] | -y [Y] | Z | Z | Z | Z | Z | Z | Z]

positional arguments:
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent

optional arguments:
  -h, --help     show this help message and exit
  -v, --verbose
  -q, --quiet
  -x [X]         the base
  -y [Y]         the exponent

% python3 31768.py 8
usage: 31768.py [-h] [-v] [-q] [-x [X]] [-y [Y]]
                [Z] [Z] [Z] [Z] [Z] [Z] [Z] [Z]

positional arguments:
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent
  Z              the exponent

optional arguments:
  -h, --help     show this help message and exit
  -v, --verbose
  -q, --quiet
  -x [X]         the base
  -y [Y]         the exponent

----------
nosy: +eric.smith
versions:  -Python 3.4, Python 3.8
Added file: https://bugs.python.org/file47214/31768.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Wed Oct 11 18:37:34 2017
From: report at bugs.python.org (caveman)
Date: Wed, 11 Oct 2017 22:37:34 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507761454.78.0.213398074469.issue31768@psf.upfronthosting.co.za>


caveman <toraboracaveman at gmail.com> added the comment:

When | is dropped, it means that the arguments/options are no longer mutually exclusive, which renders the resultant help menu incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Wed Oct 11 18:40:58 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 11 Oct 2017 22:40:58 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507761658.68.0.213398074469.issue31768@psf.upfronthosting.co.za>


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

Good point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Wed Oct 11 18:43:59 2017
From: report at bugs.python.org (Chris Caron)
Date: Wed, 11 Oct 2017 22:43:59 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507761839.63.0.213398074469.issue31741@psf.upfronthosting.co.za>


Chris Caron <lead2gold at gmail.com> added the comment:

-- Download Instructions
* 64 Bit ver of Python v2.7 for Windows https://www.python.org/ftp/python/2.7/python-2.7.amd64.msi
* Microsoft Visual C++ Compiler for Python 2.7: https://www.microsoft.com/en-ca/download/details.aspx?id=44266. 

-- Installation Instructions
* Install Python v2.7 (run python-2.7.amd64.msi); choose default options. 
Note: In my case, i uninstalled my already installed version (for the purpose of this post) first and made sure to delete the C:\Python27 directory left behind). Then I reinstalled the package.
   Default Options:
      - Install for all users
      - Install location: C:\Python27\
      - All packages installed (5 of 5 subfeatures)
	  
** Heads up
So at this point, the C:\Python27\Lib\site-packages will contain the following: pip, setuptools,  and wheel.

-- A Starting Point
* Download the Python.Test.zip file i attached, but since you made it clear you want everything to be present in this message, i'll do my best to try to document it and paste content here: 
It's main contents is just to provide an alternative include directory called Test. In this test directory i provide six.py, odereddict, chardet, backports, socks and sockhandler.
>>>>> dir listing of Test
10/11/2017  06:04 PM    <DIR>          .
10/11/2017  06:04 PM    <DIR>          ..
10/11/2017  06:04 PM    <DIR>          backports
10/11/2017  06:04 PM    <DIR>          chardet
10/11/2017  06:04 PM             4,221 ordereddict.py
10/11/2017  06:04 PM             4,916 ordereddict.pyc
10/11/2017  06:04 PM            23,462 six.py
10/11/2017  06:04 PM            23,754 six.pyc
10/11/2017  06:04 PM            32,006 socks.py
10/11/2017  06:04 PM             2,913 sockshandler.py
10/11/2017  06:04 PM                 0 __init__.py
               7 File(s)         91,272 bytes
>>>>> End DIR Listing

Now lets introduce the second part of the zip file i provided. Test.py.  It's sitting next to (not in) the Test directory i listed above. It looks like this
>>>>> Test.py
#!/usr/bin/env python
# -*- encoding: utf-8 -*-
import sys
from os.path import join
from os.path import abspath
from os.path import dirname

print('Path Before Change: {0}'.format('\n'.join(sys.path)))
sys.path.insert(0, join(dirname(abspath(__file__)), 'Test'))
print('Path After Change: {0}'.format('\n'.join(sys.path)))

import backports
print('Backports Path: {0}'.format(backports.__path__))

import chardet
print('chardet Path: {0}'.format(chardet.__path__))

import six
print('six Path: {0}'.format(six.__file__))
>>>>> end Test.py

Those who already downloaded Test.py will notice i stripped out all of the comments.  Bear with me here, the actual code lines are still all unchanged.
I also placed the attached zip file into my root C:\ directory.  Not ideal for obvious reasons, but for this test, it makes the output small and easy to follow.

-- Script Run # 1
When i run the above script... right now... i get:
>>>>>
C:\Python.Test>python Test.py
Path Before Change: C:\Python.Test
C:\windows\system32\python27.zip
C:\Python27\DLLs
C:\Python27\lib
C:\Python27\lib\plat-win
C:\Python27\lib\lib-tk
C:\Python27
C:\Python27\lib\site-packages
Path Before Change: C:\Python.Test\Test
C:\Python.Test
C:\windows\system32\python27.zip
C:\Python27\DLLs
C:\Python27\lib
C:\Python27\lib\plat-win
C:\Python27\lib\lib-tk
C:\Python27
C:\Python27\lib\site-packages
Backports Path: ['C:\\Python.Test\\Test\\backports']
chardet Path: ['C:\\Python.Test\\Test\\chardet']
six Path: C:\Python.Test\Test\six.pyc
>>>>>

Like you said... everything is fine; it's not a python issue... but hang on...

Let's use pip and install some simple packages...
>>>>>
C:\Python.Test>pip install pylint
... lots of content flies by; but it's successful
>>>>>

Let's run our script again (same one... same content). If you're doing this from the command line, then cut and paste:
>>>>>
C:\Python.Test>python Test.py
Path Before Change: C:\Python.Test
C:\windows\system32\python27.zip
C:\Python27\DLLs
C:\Python27\lib
C:\Python27\lib\plat-win
C:\Python27\lib\lib-tk
C:\Python27
C:\Python27\lib\site-packages
Path Before Change: C:\Python.Test\Test
C:\Python.Test
C:\windows\system32\python27.zip
C:\Python27\DLLs
C:\Python27\lib
C:\Python27\lib\plat-win
C:\Python27\lib\lib-tk
C:\Python27
C:\Python27\lib\site-packages
Backports Path: ['C:\\Python27\\lib\\site-packages\\backports']
chardet Path: ['C:\\Python.Test\\Test\\chardet']
six Path: C:\Python.Test\Test\six.pyc
>>>>>

So... what should you take from this?
- backports is no longer referencing the one the PYTHONPATH (well sys.path.insert()) suggested otherwise.
- but we know it works because the other entries were loaded okay. We can see this from the 'six' and 'chardet' inport paths.

Here is where it gets really weird...
Lets install chardet:
>>>>>
C:\Python.Test>pip install chardet
... lots of content flies by; but it's successful
>>>>>

Now lets run our Test.py again:
>>>>>
C:\Python.Test>python Test.py
Path Before Change: C:\Python.Test
C:\windows\system32\python27.zip
C:\Python27\DLLs
C:\Python27\lib
C:\Python27\lib\plat-win
C:\Python27\lib\lib-tk
C:\Python27
C:\Python27\lib\site-packages
Path Before Change: C:\Python.Test\Test
C:\Python.Test
C:\windows\system32\python27.zip
C:\Python27\DLLs
C:\Python27\lib
C:\Python27\lib\plat-win
C:\Python27\lib\lib-tk
C:\Python27
C:\Python27\lib\site-packages
Backports Path: ['C:\\Python27\\lib\\site-packages\\backports']
chardet Path: ['C:\\Python.Test\\Test\\chardet']
six Path: C:\Python.Test\Test\six.pyc
>>>>>

The 'chardet' is getting imported correctly from the directory i want it to even though it's also available in the site-packages directory where the backports one is being picked up.

Here is the directory listings for you:
>>>>>
C:\Python.Test>dir C:\Python27\Lib\site-packages\backports\
 Volume in drive C has no label.
 Volume Serial Number is ACA9-DD63

 Directory of C:\Python27\Lib\site-packages\backports

10/11/2017  06:30 PM    <DIR>          .
10/11/2017  06:30 PM    <DIR>          ..
10/11/2017  06:30 PM    <DIR>          configparser
10/11/2017  06:30 PM             7,317 functools_lru_cache.py
10/11/2017  06:30 PM             7,378 functools_lru_cache.pyc
10/11/2017  06:30 PM                65 __init__.py
>>>>>

>>>>>
C:\Python.Test>dir Test\backports
 Volume in drive C has no label.
 Volume Serial Number is ACA9-DD63

 Directory of C:\Python.Test\Test\backports

10/11/2017  06:04 PM    <DIR>          .
10/11/2017  06:04 PM    <DIR>          ..
10/11/2017  06:04 PM    <DIR>          ssl_match_hostname
10/11/2017  06:04 PM                38 __init__.py
10/11/2017  06:04 PM               227 __init__.pyc
               2 File(s)            265 bytes
>>>>>

I realize i'm frustrating you with my request, but hopefully this helps explain the problem better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Wed Oct 11 19:50:27 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 11 Oct 2017 23:50:27 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507765827.08.0.213398074469.issue31757@psf.upfronthosting.co.za>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Wed Oct 11 20:45:57 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 00:45:57 +0000
Subject: [issue31767] Windows Installer fails with error 0x80091007 when
 trying to install debugging symbols
In-Reply-To: <1507756995.05.0.213398074469.issue31767@psf.upfronthosting.co.za>
Message-ID: <1507769157.33.0.213398074469.issue31767@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31767>
_______________________________________

From report at bugs.python.org  Wed Oct 11 20:46:15 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 12 Oct 2017 00:46:15 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507769175.92.0.213398074469.issue31558@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

>> This is only useful if the parent process has a lot of memory that's never used by the child processes right? Otherwise, you would lose via refcounting COWs.
>
> What we saw in prod is that memory fragmentation caused by gc is the main reason of shared memory shrink.
>
> The memory fragmentation is figured out by doing a full collection before fork and keep it disabled, it'll make a bunch of copy-on-write in child process.

GC doesn't cause "memory fragmentation".
GC touches (writes) GC header and refcount.  It cause sharing memory shrink.
Maybe, you're wrongly understanding "memory fragmentation".

> This can't solve the copy-on-write caused by ref count, but we're thinking about freezing the ref count on those permanent objects too.

It may increase cost of refcount operation, because it makes all INCREF and DECREF bigger.
Note that this is only helps application using gc.freeze().  This shouldn't slow down all other applications.

> So this is useful if you did some warm-up work in parent process.

I don't understand this statement.

> Also it could speedup gc if you have large amount of permanent objects.

Yes, this helps not only "prefork" application, but also all long running applications
having large baseline data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Wed Oct 11 20:51:06 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 12 Oct 2017 00:51:06 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507769466.67.0.213398074469.issue31558@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

As Instagram's report, disabling cycler GC really helps even if there is refcont.
All application have some cold data: imported but never used modules, functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Wed Oct 11 20:52:08 2017
From: report at bugs.python.org (Chris Caron)
Date: Thu, 12 Oct 2017 00:52:08 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507769528.82.0.213398074469.issue31741@psf.upfronthosting.co.za>


Chris Caron <lead2gold at gmail.com> added the comment:

Just to point out, i forgot the instructions of installing pip (right before) the following entry in my last post:
>> ** Heads up
>> So at this point, the C:\Python27\Lib\site-packages will contain the >>> following: pip, setuptools,  and wheel.

To be thorough, i should add that that i followed these instruction: https://pip.pypa.io/en/stable/installing/

Which required me to download get-pip.py from here https://bootstrap.pypa.io/get-pip.py and run it.  The rest of the instructions (after the **heads up) comment are still all on note.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Wed Oct 11 20:56:15 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 12 Oct 2017 00:56:15 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507769775.86.0.213398074469.issue31558@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Should gc.freeze() do gc.collect() right before freezing?
Or should we document `gc.collect(); gc.freeze();` idiom?

I don't like `gc.freeze(collect=False)`.
So if there is at least one use case of `gc.freeze()` without `gc.collect()`, I'm +1 on former (current pull request) design.


Other nitpicking: get_freeze_count() or get_frozen_count()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Wed Oct 11 21:06:25 2017
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 12 Oct 2017 01:06:25 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1507770385.64.0.213398074469.issue2506@psf.upfronthosting.co.za>


Alex Gaynor <alex.gaynor at gmail.com> added the comment:

If anyone has needed a workaround in the past 9 years and hasn't yet found one: https://github.com/pyca/cryptography/pull/3968/commits/3b585f803891e750d0ca5861b5a29e16b779bc16

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Wed Oct 11 21:38:32 2017
From: report at bugs.python.org (Daisuke Miyakawa)
Date: Thu, 12 Oct 2017 01:38:32 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507772312.65.0.213398074469.issue31567@psf.upfronthosting.co.za>


Change by Daisuke Miyakawa <d.miyakawa at gmail.com>:


----------
keywords: +patch
pull_requests: +3935
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Wed Oct 11 21:41:33 2017
From: report at bugs.python.org (Zekun Li)
Date: Thu, 12 Oct 2017 01:41:33 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507772493.85.0.213398074469.issue31558@psf.upfronthosting.co.za>


Zekun Li <li.zekun at gmail.com> added the comment:

So what we did is:

We keep gc **disabled** on parent process and freeze after warmup, enable gc on child process.

The reason not to do a full collection is mentioned in previous comments/original ticket - (I called it) memory fragmentation.

The observation is - We keep gc disabled on both parent and child process and did a full collection before fork, it makes the shared memory shrink a lot compared to no collection. - There's no way for disabled gc to touch the head to make copy-on-write.

Of course, enable gc will make the shared memory shrink more. But the former case is accounting more than latter one.

So my understand is that gc frees some objects and makes some memory pages becomes available to allocate in child process. Allocation on the shared memory pages will cause the copy-on-write even without gc.

Though this behavior may have better name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Wed Oct 11 21:52:17 2017
From: report at bugs.python.org (Tim Peters)
Date: Thu, 12 Oct 2017 01:52:17 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
In-Reply-To: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>
Message-ID: <1507773137.38.0.213398074469.issue31759@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Sure!  The OP was obviously asking about the engine that ships with Python, so that's what I talked about.

Rapha?l, Matthew develops an excellent replacement ("regex") for Python's re module, which you can install via, e.g., "pip install regex" (or, on Windows, "python -m pip install regex").  More info here:

https://pypi.python.org/pypi/regex/

Matthew, will that become Python's standard offering some day?  I'd be in favor of that!  It has many advantages, although it doesn't always avoid exponential-time backtracking in failing cases.  For example, `re` and `regex` both take exponential time to fail to match the regexp:

"((xy)+)+$"

against strings of the form:

"xy" * i + "y"

Increase `i` by 1, and both take about twice as long to fail to match (meaning either .match or .search), and `re` is actually quicker on my box (3.6.3 on 64-bit Win10).

In any case, I'm closing this, since there's no concrete idea on the table for a change to `re` that would actually help (e.g., people ignore warnings, and there's really no way to _guess_ whether a regexp is "taking too long" to begin with - if it's taking minutes, people immediately discover the hangup already when they interrupt the program and see that it's trying to match a regexp).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Wed Oct 11 22:34:51 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 Oct 2017 02:34:51 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1507775691.14.0.213398074469.issue31756@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As far as docs phrasing goes, it probably makes sense to frame it as "text" being the preferred argument name in 3.7+, with "universal_newlines" retained indefinitely as a compatibility preserving alias. After all, if that wasn't our intention, we wouldn't be adding the more straightforward alias in the first place.

As a new Py3-only argument, "text" can also be made keyword-only. (The Popen arg list is so long that most folks treat everything other than the first item as keyword-only anyway, but it doesn't hurt to ask the interpreter to enforce that)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Wed Oct 11 22:46:41 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 Oct 2017 02:46:41 +0000
Subject: [issue14369] make __closure__ writable
In-Reply-To: <1332179477.04.0.11685261564.issue14369@psf.upfronthosting.co.za>
Message-ID: <1507776401.76.0.213398074469.issue14369@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thinking about the interaction between this idea and https://bugs.python.org/issue30744 made me realise that there's a subtlety here that would probably need to be spelled out more clearly in the docs for __closure__ than it is for __code__: any changes made to a function object (whether it's a synchronous function, a generator, or a coroutine) will only affect *future* function invocations, as execution frames capture references to both the code object and all the closure cells when they're created.

(Thought prompted by asking myself "What would happen to existing generator-iterators if you rebound the closure on the generator function?". The answer is "Nothing", but I figure if I had to think about it, that answer likely isn't going to be obvious to folks that are less familiar with how the eval loop works in practice)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14369>
_______________________________________

From report at bugs.python.org  Wed Oct 11 23:33:29 2017
From: report at bugs.python.org (Mike Gilbert)
Date: Thu, 12 Oct 2017 03:33:29 +0000
Subject: [issue31769] configure includes user CFLAGS testing detecting
 pthreads support
Message-ID: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>


New submission from Mike Gilbert <floppymaster at gmail.com>:

When testing for ptheads support in the compiler, configure includes the CFLAGS value from the environment.

If CFLAGS contains -pthread, or an option which implies -pthread (like -fopenmp), this will cause configure to not include -pthread in the CC variable, and -pthread will not be passed to the linker.

This ultimately leads to a link failure when building with glibc/gcc.

gcc   -Xlinker -export-dynamic -o python Programs/python.o libpython3.7m.a -ldl  -lutil   -lm  
libpython3.7m.a(thread.o): In function `PyThread_start_new_thread':
/home/floppym/src/cpython/Python/thread_pthread.h:191: undefined reference to `pthread_attr_setstacksize'

----------
components: Build
messages: 304200
nosy: floppymaster
priority: normal
severity: normal
status: open
title: configure includes user CFLAGS testing detecting pthreads support
type: compile error
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Wed Oct 11 23:34:52 2017
From: report at bugs.python.org (Mike Gilbert)
Date: Thu, 12 Oct 2017 03:34:52 +0000
Subject: [issue31769] configure includes user CFLAGS testing detecting
 pthreads support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507779292.01.0.213398074469.issue31769@psf.upfronthosting.co.za>


Change by Mike Gilbert <floppymaster at gmail.com>:


Added file: https://bugs.python.org/file47215/configure.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Wed Oct 11 23:35:21 2017
From: report at bugs.python.org (Mike Gilbert)
Date: Thu, 12 Oct 2017 03:35:21 +0000
Subject: [issue31769] configure includes user CFLAGS testing detecting
 pthreads support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507779321.0.0.213398074469.issue31769@psf.upfronthosting.co.za>


Change by Mike Gilbert <floppymaster at gmail.com>:


Added file: https://bugs.python.org/file47216/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Wed Oct 11 23:36:08 2017
From: report at bugs.python.org (Mike Gilbert)
Date: Thu, 12 Oct 2017 03:36:08 +0000
Subject: [issue31769] configure includes user CFLAGS testing detecting
 pthreads support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507779368.3.0.213398074469.issue31769@psf.upfronthosting.co.za>


Mike Gilbert <floppymaster at gmail.com> added the comment:

To resolve this, I suggest clearing CFLAGS/CXXFLAGS before performing the ptheads check, and restoring them afterward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Thu Oct 12 00:11:32 2017
From: report at bugs.python.org (Louie Lu)
Date: Thu, 12 Oct 2017 04:11:32 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507781492.49.0.213398074469.issue31768@psf.upfronthosting.co.za>


Louie Lu <me at louie.lu> added the comment:

the format of usage is do at argparse.py:296.

So how do we format this kind of situation,
to be like this, if the group also too long?

  usage: test.py [-h]
                 [-v | -q | -x [X] | -y [Y] | Z | Z | Z | Z | Z |
                  Z | Z | Z]


Also, another bug I think is, given two mutul group,
it will not show out the correct grouping:

usage: test.py [-h] [-v] [-e] [Z] [G] [Z] [G]

positional arguments:
  Z              the exponent
  G              the exponent
  Z              the exponent
  G              the exponent

optional arguments:
  -h, --help     show this help message and exit
  -v, --verbose
  -e, --eeeeee


--- 2 mutul group ---

import sys
import argparse
parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group()
group.add_argument("-v", "--verbose", action="store_true")
g2 = parser.add_mutually_exclusive_group()
g2.add_argument("-e", "--eplog", action="store_true")
g2.add_argument("-g", "--quiet", action="store_true")

for i in range(int(sys.argv[1])):
    group.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')
    g2.add_argument("z", metavar='Z', type=str, help="the exponent", nargs='?')

parser.parse_args(['-h'])

----------
nosy: +louielu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Thu Oct 12 00:22:11 2017
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Oct 2017 04:22:11 +0000
Subject: [issue31769] configure includes user CFLAGS testing detecting
 pthreads support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507782131.39.0.213398074469.issue31769@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Thu Oct 12 00:25:08 2017
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Oct 2017 04:25:08 +0000
Subject: [issue31769] configure includes user CFLAGS testing detecting
 pthreads support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507782308.41.0.213398074469.issue31769@psf.upfronthosting.co.za>


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


----------
assignee:  -> twouters
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Thu Oct 12 00:27:13 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 12 Oct 2017 04:27:13 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1507782433.53.0.213398074469.issue31558@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

> So my understand is that gc frees some objects and makes some memory pages becomes available to allocate in child process. Allocation on the shared memory pages will cause the copy-on-write even without gc.
>
> Though this behavior may have better name?

OK, now I got what you're talking.
I don't know proper name about it.  I call it as "memory hole" for now.

But I don't think "memory hole" is big problem, because we already has refcount.
Say there are 100 function objects in one page, and 99 of them are never used. But when 1 of them are called, the page is unshared.

Solving memory hole issue is easy: just stop allocating new object from existing pages.
But I don't think it's worth enough because of refcount issue.

Instead of trying "share most data", I recommend to "use small number of processes" approach.

In my company, we don't use "prefork", but "--lazy-app" option of uWSGI for graceful reloading. (e.g. "afterfork")
But since we use nginx in front of uWSGI, # of uWSGI worker is just 2* CPU cores.  We can serve to massive clients from only 16~32 processes.

So I prefer optimizing normal memory usage.  It is good for all applications, not only "prefork" applications.

In this case, I'm +1 to gc.freeze() proposal because it can be used for single process applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Thu Oct 12 00:30:28 2017
From: report at bugs.python.org (Mike Gilbert)
Date: Thu, 12 Oct 2017 04:30:28 +0000
Subject: [issue31769] configure includes user CFLAGS when detecting pthreads
 support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507782628.91.0.213398074469.issue31769@psf.upfronthosting.co.za>


Change by Mike Gilbert <floppymaster at gmail.com>:


----------
title: configure includes user CFLAGS testing detecting pthreads support -> configure includes user CFLAGS when detecting pthreads support

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Thu Oct 12 00:54:17 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Oct 2017 04:54:17 +0000
Subject: [issue13802] IDLE Prefernces/Fonts: use multiple alphabets in examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507784057.87.0.213398074469.issue13802@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +3937
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 01:05:21 2017
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 12 Oct 2017 05:05:21 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507784721.78.0.213398074469.issue31741@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Note that your instructions start with downloading the installer for 2.7.0, whereas the latest version of 2.7 is 2.7.14, which includes pip.

backports is a strange beast of a package, which tries to emulate Python 3's namespace packages in Python 2.  To do so, backports.__init__ must have a very specific incantation, which yours is lacking (it only contains "from __future__ import absolute_import").  See https://pypi.org/project/backports/ for more details.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Thu Oct 12 01:07:54 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Oct 2017 05:07:54 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507784874.05.0.213398074469.issue13802@psf.upfronthosting.co.za>


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

I decided to do the needed rearrangement of frames in this issue, leaving revision of widgets other than the sample to #24776.

PR3960 initially puts the following in the sample box.  I believe it should cover most Python users.

<ASCII/Latin1>
AaBbCcDdEeFfGgHhIiJj
1234567890#:+=(){}[]
????????????????????

<IPA,Greek,Cyrillic>
????????????????????
????????????????????
????????????????????

<Hebrew, Arabic>
????????????????????
????????????????????

<Devanagari>
????????????????????
????????????????????

<East Asian>
??????????
??????????
??????????
??????????

The new help message explains

Font sample: This shows what a selection of BMP unicode characters look
like for the current font selection.  If a font face does not define a
character, Tk attempts to find another font that does.  Substitute
glyphs will not necessarily have the same size as the font selected.
Hebrew and Arabic letters should display right to left, starting with
alef, \u05d0 and \u0627.  Arabic numerals display left to right.  The
East Asian samples are Chinese digits followed by Chinese Hanzi, Korean
Hangul, and Japanese Hiragana.

Except for Chinese, I intend for the samples to be meaningless subsequences of the respective character set.  I will try to get comments from others for the Indian, Korean, and Japanese samples.

The Chinese reads 'hanzi hanzi person wood fire earth metal water' with 'hanzi' repeated in simplified and traditional character variations.  Louie, could this be controversial in any way?

----------
dependencies:  -IDLE: Improve config dialog font change user interface
title: IDLE Prefernces/Fonts: use multiple alphabets in examples -> IDLE font settings: use multiple character sets in examples

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 01:35:06 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 05:35:06 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507786506.68.0.213398074469.issue30767@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 01:58:58 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 05:58:58 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507787938.32.0.213398074469.issue28647@psf.upfronthosting.co.za>


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


----------
pull_requests: +3938
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 01:58:58 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 05:58:58 +0000
Subject: [issue30404] Make stdout and stderr truly unbuffered when using -u
 option
In-Reply-To: <1495209125.34.0.468493818937.issue30404@psf.upfronthosting.co.za>
Message-ID: <1507787938.43.0.00913614298617.issue30404@psf.upfronthosting.co.za>


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


----------
pull_requests: +3939

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30404>
_______________________________________

From report at bugs.python.org  Thu Oct 12 02:00:37 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 06:00:37 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507788037.26.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Good catch, I thought it was already fixed in master after bpo-30404. I've opened PR 3961.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 02:18:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 06:18:55 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507789135.04.0.213398074469.issue28647@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Don't forget to update Misc/python.man.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 02:58:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 06:58:18 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507791498.74.0.213398074469.issue30767@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 3792 breaks existing tests, and it seems to me, that it solves different issue, than reported here.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:18:46 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 12 Oct 2017 07:18:46 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507792726.72.0.213398074469.issue30767@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is not an issue that needs fixing; the current behaviour is by design. The documentation states about exc_info:

"There are two keyword arguments in kwargs which are inspected: exc_info which, if it does not evaluate as false, causes exception information to be added to the logging message. If an exception tuple (in the format returned by sys.exc_info()) is provided, it is used; otherwise, sys.exc_info() is called to get the exception information."

So, an individual exception instance returning false will not affect the truthiness of an exc_info tuple (if provided). I propose to close this issue as "not a bug" and reject the PR because (a) there's no issue to fix and (b) what Serhiy said.

If you still think there's an issue here, please post an example script which uses logging as documented and demonstrates a problem.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:27:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 07:27:27 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507793247.0.0.213398074469.issue13802@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think empty lines and headers are not needed. They just increase the size of the dialog window, it may be too large for low resolution screens.

The standard font chooser on Windows uses the following sets for Unicode-aware fonts: Western, Cyrillic, Hebrew, Arabic, Greek, Turkish, Baltic (doesn't differ from Western), Central-European, Vietnamese. I think it is worth to decrease the Devanagari sample and add few Central-European (????), Turkish (????) and Vietnamese (????) characters. Maybe decrease the size of all non-ASCII samples? 2-3 letters (in upper and lower cases) should be enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:43:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 07:43:25 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507794205.39.0.213398074469.issue28647@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The -u option doesn't affect the buffering of stdin. Is it worth to document this explicitly? Or it just adds a noise? Maybe remove this from the help and manpage but add in the RST documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:44:23 2017
From: report at bugs.python.org (Louie Lu)
Date: Thu, 12 Oct 2017 07:44:23 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507794263.19.0.213398074469.issue13802@psf.upfronthosting.co.za>


Louie Lu <me at louie.lu> added the comment:

PR 3960 display on my Linux works well, and the combination of the Chinese characters has no political controversial.

But it is lack of simplify characters, the only one is '?', others are all traditional characters (or they are same in simp. and trad.).

For Japanese, there are katakana (????), hiragana(????) and kanji (??), the characters you provide only contain hiragana. Maybe a sentence that contains all kinds of characters will be better.

For Korean, the characters are compound to one, but I'm not sure will they use the first four characters to test the font. CC for corona10.

For Chinese, Japanese, Korean, I'll still prefer and recommend to use a sentence to give user the perspective of the font.


For other character set, maybe we can reference from Google fonts:
https://fonts.google.com/
they got a list of Unicode-aware language:

    Arbic, Bengali, Cyrillic, Cyrillic Extended, Devanagari, Greek,
    Greek Extended, Gujarati, Gurmukhi, Hebrew, Kannada, Khmer,
    Latin, Latin Extended, Malayalam, Myanmar, Oriya, Tamil, Telugu,
    Thai, Vietnamese.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:45:58 2017
From: report at bugs.python.org (Paul Moore)
Date: Thu, 12 Oct 2017 07:45:58 +0000
Subject: [issue31741] backports import path can not be overridden in Windows
 (Linux works fine)
In-Reply-To: <1507585685.64.0.213398074469.issue31741@psf.upfronthosting.co.za>
Message-ID: <1507794358.27.0.213398074469.issue31741@psf.upfronthosting.co.za>


Paul Moore <p.f.moore at gmail.com> added the comment:

Also, one of the packages installed creates a file

configparser-3.5.0-py2.7-nspkg.pth

This has some very suspicious looking content:

import sys, types, os;has_mfs = sys.version_info > (3, 5);p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('backports',)); importlib = has_mfs and __import__('importlib.util');has_mfs and __import__('importlib.machinery');m = has_mfs and sys.modules.set default('backports', importlib.util.module_from_spec(importlib.machinery.PathFinder.find_spec('backports', [os.path.dirname(p)]))) ;m = m or sys.modules.setdefault('backports', types.ModuleType('backports'));mp = (m or []) and m.__dict__.setdefault('__path__',[ ]);(p not in mp) and mp.append(p)

That's likely your problem. I've no idea what it's doing, but as Zachary says, the backports module is a strange beast...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31741>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:48:04 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Oct 2017 07:48:04 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507794484.02.0.213398074469.issue31732@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I vote against this on the ground that five levels have sufficed for a long and that the need for finer distinctions almost never arises in practice.  There would be an ongoing mental cost to making users learn and think about finer levels of distinction.

----------
assignee:  -> vinay.sajip
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:53:59 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Oct 2017 07:53:59 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1507794839.83.0.213398074469.issue31753@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I prefer the existing code and think this shouldn't be changed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:55:16 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 07:55:16 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507794916.66.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I think it's better to be explicit and mention 'stdin' in this case. Plus, "stdin is always buffered" is quite short so potential of creating noise is quite minimal IMO.

(FYI, I asked this question on GitHub: https://github.com/python/cpython/pull/3961#issuecomment-336035358)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 03:57:15 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Oct 2017 07:57:15 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507795035.93.0.213398074469.issue30767@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I agree that this should be closed.

----------
nosy: +rhettinger
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 04:06:24 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Oct 2017 08:06:24 +0000
Subject: [issue31763] Add NOTICE level to the logging module
In-Reply-To: <1507747705.55.0.213398074469.issue31763@psf.upfronthosting.co.za>
Message-ID: <1507795584.4.0.213398074469.issue31763@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

As mentioned in the other tracker item, I'm against adding another level.  While it might serve an exotic need, I think most users would be worse off having to learn and think about yet another level of distinction.  The mental costs would be on going.

FWIW, users already have the ability to define new levels (as simply as: SEMI_INTERESTING=25) but we rarely see this in practice.  The long and successful history of this module is somewhat strong evidence that the current five levels suffice for most users, most of the time.

----------
assignee:  -> vinay.sajip
nosy: +rhettinger, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31763>
_______________________________________

From report at bugs.python.org  Thu Oct 12 04:12:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 08:12:58 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507795978.64.0.213398074469.issue13802@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I suggest to make the sample text editable:

    self.font_sample = Text(frame_sample, font=temp_font, width=20)
    self.font_sample.insert(END, sample)

This will allow a user to test fonts in any perspective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 04:18:36 2017
From: report at bugs.python.org (Oren Milman)
Date: Thu, 12 Oct 2017 08:18:36 +0000
Subject: [issue31770] crash and refleaks when calling
 sqlite3.Cursor.__init__() more than once
Message-ID: <1507796316.87.0.213398074469.issue31770@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code crashes:
import sqlite3
import weakref
def callback(*args):
    pass

connection = sqlite3.connect(":memory:")
cursor = sqlite3.Cursor(connection)
ref = weakref.ref(cursor, callback)
cursor.__init__(connection)
del cursor
del ref

IIUC, this is because pysqlite_cursor_init() (in Modules/_sqlite/cursor.c) sets
`self->in_weakreflist` to NULL, and thus corrupts the weakref list. Later,
clear_weakref() (in Objects/weakrefobject.c) tries to remove a reference from
the corrupted list, and crashes.

In every other place (that i saw) where such a weakreflist field is used, it is
set to NULL right after allocating the object (usually in __new__()), or just
not set at all, e.g. in `functools.partial`.
So since PyType_GenericNew() is the __new__() of sqlite3.Cursor, ISTM that the
simplest solution is to not touch `self->in_weakreflist` at all in
pysqlite_cursor_init().


Also, the following code results in refleaks:
import sys
import sqlite3
connection = sqlite3.connect(":memory:")
cursor = sqlite3.Cursor(connection)
refcount_before = sys.gettotalrefcount()
cursor.__init__(connection)
print(sys.gettotalrefcount() - refcount_before)  # should be close to 0

This is because pysqlite_cursor_init() doesn't decref before assigning to
fields of `self`.


I would open a PR to fix this soon.

----------
components: Extension Modules
messages: 304220
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crash and refleaks when calling sqlite3.Cursor.__init__() more than once
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31770>
_______________________________________

From report at bugs.python.org  Thu Oct 12 04:37:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 08:37:26 +0000
Subject: [issue31770] crash and refleaks when calling
 sqlite3.Cursor.__init__() more than once
In-Reply-To: <1507796316.87.0.213398074469.issue31770@psf.upfronthosting.co.za>
Message-ID: <1507797446.16.0.213398074469.issue31770@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31770>
_______________________________________

From report at bugs.python.org  Thu Oct 12 04:52:29 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 08:52:29 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1507798349.04.0.213398074469.issue31753@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I prefer the existing code too.

But I'm surprised that this change has a measurable effects at all. I thought that creating a closure is cheaper. Of course it is much faster than creating a class. Maybe it is worth to spend some time for optimizing closure creation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:16:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 09:16:23 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507799783.75.0.213398074469.issue31761@psf.upfronthosting.co.za>


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


----------
components: +Tests -Documentation
title: Possible error in devguide part about tests -> regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:26:06 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 12 Oct 2017 09:26:06 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507800366.58.0.213398074469.issue13802@psf.upfronthosting.co.za>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Louie Lu 

Thanks for the cc.
In Korea, '??????????' are not recommended characters sequence.
This sequence is not fully cover Korean characters.

FYI, 
MS Windows default font preview sequence is 
'??? ? ???? ???'

Google chrome preview sequence is
'? ?? ??? ?? ? ?? ?? ?? ?? ?'

Those two sequences are the Korean version of 'The quick brown fox jumps over the lazy dog'.

If you want to use Korean version of 'AaBbCcDdEeFfGgHhIiJj'
I recommend '??????????????'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:37:14 2017
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 12 Oct 2017 09:37:14 +0000
Subject: [issue31769] configure includes user CFLAGS when detecting pthreads
 support
In-Reply-To: <1507779209.22.0.213398074469.issue31769@psf.upfronthosting.co.za>
Message-ID: <1507801034.36.0.213398074469.issue31769@psf.upfronthosting.co.za>


Change by Chi Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31769>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:40:07 2017
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 12 Oct 2017 09:40:07 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507801207.3.0.213398074469.issue13802@psf.upfronthosting.co.za>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

'??????????????' is better than '?????????????'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:42:37 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 09:42:37 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507801357.38.0.213398074469.issue25588@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3940
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:49:43 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 09:49:43 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507801783.49.0.213398074469.issue25588@psf.upfronthosting.co.za>


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

I proposed PR 3962 to fix a few issues in regrtest when sys.stdout and sys.stderr have to file descriptor.

I'm not sure that we should promote running tests with unusual sys.stdout and sys.stderr, since many tests fail in that case. That's why I chose to not add a NEWS entry to my PR.

For example, test_builtin hangs until you write something in IDLE, whereas no prompt is displayed. test_faulthandler fails, and much more tests. I'm not interested to support running the Python test suite in IDLE.

Maybe we should even detect that we are running in IDLE and fail with an helpful error message like :

"Running the Python test suite inside IDLE is not supported. Run the test suite in a terminal."

At least, write a warning in UPPERCASE if sys.stdout or sys.stderr have no file descriptor?

----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Thu Oct 12 05:51:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 09:51:16 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507801876.5.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

> "If you don?t have easy access to a command line, you can run the test suite from a Python or IDLE shell:

The devguide is wrong. You should not run the Python test suite in IDLE. It doesn't work and many tests fail just because of IDLE.

Please run the test suite in a command line (like "cmd.exe" on Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 06:05:31 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 10:05:31 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507802731.25.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

Raymond Hettinger: "... the need for finer distinctions almost never arises in practice"

I gave a list of 10 projects which are alreading using widely the 6th TRACE level.

In this list, I consider that OpenStack and SaltStack are two big and serious projects which justify to add the TRACE level in the stdlib. It will avoid these projects to have to "patch" the stdlib for their need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Thu Oct 12 06:25:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 10:25:12 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507803912.36.0.213398074469.issue25588@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it would be nice to make testing so flexible as possible. This would help to get rid of unintended assumptions. If some tests are failed on IDLE I would prefer to fix or skip only these tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Thu Oct 12 07:05:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 11:05:33 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507806333.95.0.213398074469.issue28647@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In Python 2 there is an internal buffering in xreadlines(), readlines() and file-object iterators. You need to enter many lines first that the program get the first of them. And -u doesn't help.

But in Python 3 the program gets the input right as it becomes available. Reading is not blocked if the input is available. There are internal buffers, but they affect only performance, not the behavior. If you can edit a line before pressing Enter, this is because your terminal buffers a line before sending it to the program. I think it is more correct to say that stdin is always unbuffered in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 07:47:40 2017
From: report at bugs.python.org (pmpp)
Date: Thu, 12 Oct 2017 11:47:40 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507808860.24.0.213398074469.issue31732@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

As a dumb user I vote in favor of this on the ground that five levels is not sufficient for a long and that the need for finer distinctions already arose for me in practice.  Till i overcame the mental cost to think, learn and *find time* on how to make a finer level of distinction to work.

line tracing logging is a level on its own and doesn't fit with provided ones which are *too simple*.

--

If python is "battery included". It's time to provide a multiplatform charger ...

----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:12:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 13:12:09 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507813929.38.0.213398074469.issue25588@psf.upfronthosting.co.za>


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

Serhiy: "If some tests are failed on IDLE I would prefer to fix or skip only these tests."

Ok, go ahead. There are many failing tests :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:15:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 13:15:16 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507814116.05.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

Serhiy: "(...) I think it is more correct to say that stdin is always unbuffered in Python 3."

I disagree. Technically, sys.stdin.read(1) reads up to 1024 bytes from the file descriptor 0. For me, "unbuffered read" means that read(1) reads a single byte.

Expected behaviour of an fully unbuffered stdin:

assert sys.stdin.read(1) == 'a'
assert os.read(0, 1) == b'b'

The program should not fail with an assertion error nor block if you write 'ab' characters into stdin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:26:16 2017
From: report at bugs.python.org (Peter J)
Date: Thu, 12 Oct 2017 13:26:16 +0000
Subject: [issue31771] tkinter geometry string +- when window ovelaps left or
 top of screen
Message-ID: <1507814776.62.0.213398074469.issue31771@psf.upfronthosting.co.za>


New submission from Peter J <peterj.13.07 at gmail.com>:

the root.geometry() top-level window method returns strings like "212x128+-9+-8" when the window is located in the top left corner. The documentation only describes geometry strings containing + or - location coordinates. If this is correct behaviour, the documentation should provide a better description of the syntax - perhaps a regular expression such as: "\d+x\d+(\+|-|\+-)\d+(\+|-|\+-)\d+" and some text indicating that a +- coordinate indicates a value to the left of or above the screen.

Tested Linux Mint 18, Python 3.5.3, tkinter 8.6

Behaviour is consistent with python 2.7 Tkinter 8.6

----------
components: Tkinter
messages: 304232
nosy: 8baWnoVi
priority: normal
severity: normal
status: open
title: tkinter geometry string +- when window ovelaps left or top of screen
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31771>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:26:44 2017
From: report at bugs.python.org (Matthew Patton)
Date: Thu, 12 Oct 2017 13:26:44 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507814804.53.0.213398074469.issue30767@psf.upfronthosting.co.za>


Matthew Patton <pattonme at yahoo.com> added the comment:

"exc_info which, if it does not evaluate as false", so we provide '1' or 'True'. The IF passes and immediately the formatter tries to dereference it blindly assuming it's Tuple and throws an Exception.

Either the Formatter needs to guard itself (best) or the caller needs to check the Type before allowing a call to the Formatter to go thru.

Should sys.exc_info() have already been called then the Tuple can have a valid frame reference or it's 3 None's. In this last case the Formatter is emitting a naked, zero context "NoneType None" line into the middle of the stack trace which is just annoying and pointless.

Again, I probably should have written the guard at the formatter to emit nothing when the field is None. It actually checks for the 2nd and 3rd fields, not the first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:37:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 13:37:55 +0000
Subject: [issue31771] tkinter geometry string +- when window ovelaps left or
 top of screen
In-Reply-To: <1507814776.62.0.213398074469.issue31771@psf.upfronthosting.co.za>
Message-ID: <1507815475.67.0.213398074469.issue31771@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tkinter is just a wrapper around the Tk library. It returns what Tk returns. See Tk documentation:

https://www.tcl.tk/man/tcl8.6/TkCmd/winfo.htm#M15
https://www.tcl.tk/man/tcl8.6/TkCmd/wm.htm#M42

If you want to improve Tkinter documentation, patches are welcome.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, serhiy.storchaka
type: behavior -> enhancement
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31771>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:39:18 2017
From: report at bugs.python.org (Matthew Patton)
Date: Thu, 12 Oct 2017 13:39:18 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507815558.9.0.213398074469.issue30767@psf.upfronthosting.co.za>


Matthew Patton <pattonme at yahoo.com> added the comment:

Additionally (probably should have separate PR) the _checkLevel was full of holes.
First, it's allowing any Integer which if you're claiming to "check" things is rather silly. At least bounds-check it to GE to NOTSET and LE to CRITICAL (or MAX or something handy in that regard).

Second, why is a string representation of an Integer a problem that needs to force the caller to fix his code? Same with lowercase of a recognized value. "Be liberal in what you accept" would seem to apply here. If it can be trivially reduced to an integer or upcased() to get a match then just do it, and send the corrected value back to the caller.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:43:00 2017
From: report at bugs.python.org (Devin Bayer)
Date: Thu, 12 Oct 2017 13:43:00 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
Message-ID: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>


New submission from Devin Bayer <dev at doubly.so>:

The current import machinery will use stale cached bytecode if the source is modified more than once per second and with equal size.

A straightforward fix is to require the bytecode mtime to be greater than the source file mtime. In the unusual case where the file is written twice with the precision the filesystem records, this will ignore the cache, but at least we aren't behaving incorrectly.

----------
components: Interpreter Core
messages: 304236
nosy: akvadrako
priority: normal
severity: normal
status: open
title: SourceLoader uses stale bytecode in case of equal mtime seconds
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:45:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 13:45:45 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507815945.52.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

Serhiy Storchaka:
https://github.com/python/cpython/pull/3961#issuecomment-336136160

"I suggest to continue the discussion on the tracker."

Ok, let's continue here.

"We are fixing the outdated documentation inherited from Python 2. First than keep some statement we should consider what it means in the context of Python 2 and what it means in the context of Python 3."

stdin buffering is a complex thing.

When running the UNIX command "producer | consumer", many users are confused by the buffering on the *producer* side.

When running a program in a TTY, the TTY does line buffering for you, you cannot get immediately a single character (without changing the default TTY configuration).

I don't think that we need to say too much. I just suggest to say "stdin is always buffered". That's all.

See my previous messages for the my definition of "buffered" versus "unbuffered" read.

Note: Today I learned the UNIX "stdbuf" command, useful to configure the stdin, stdout and stderr buffering of C applications using <stdio.h>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:48:08 2017
From: report at bugs.python.org (Matthew Patton)
Date: Thu, 12 Oct 2017 13:48:08 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507816088.91.0.213398074469.issue30767@psf.upfronthosting.co.za>


Matthew Patton <pattonme at yahoo.com> added the comment:

And the reason to stomp on the "Level " is because by not doing so the message that is a single field (regex/awk) has been converted non-deterministically into two. This is very bad behavior. If emitting the string/int as-is looks wrong then "Level(value)" or some other notation that keeps it a single field is how it should print.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 09:48:09 2017
From: report at bugs.python.org (Devin Bayer)
Date: Thu, 12 Oct 2017 13:48:09 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507816089.24.0.213398074469.issue31772@psf.upfronthosting.co.za>


Change by Devin Bayer <dev at doubly.so>:


----------
keywords: +patch
pull_requests: +3941
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:14:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 14:14:14 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
Message-ID: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>


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

The commit a997c7b434631f51e00191acea2ba6097691e859 of bpo-31415 moved the implementation of time.perf_counter() from Modules/timemodule.c to Python/pytime.c. The change not only moved the code, but also changed the internal type storing time from floatting point number (C double) to integer number (_PyTyime_t = int64_t).

The drawback of this change is that time.perf_counter() now converts QueryPerformanceCounter() / QueryPerformanceFrequency() double into a _PyTime_t (integer) and then back to double. Two useless conversions required by the _PyTime_t format used in Python/pytime.c. These conversions introduced a loss of precision.

Try attached round.py script which implements the double <=> _PyTime_t conversions and checks to check for precision loss. The script shows that we loose precision even with a single second for QueryPerformanceFrequency() == 3579545.

It seems like QueryPerformanceFrequency() now returns 10 ** 7 (10_000_000, resolution of 100 ns) on Windows 8 and newer, but returns 3,579,545 (3.6 MHz, resolution of 279 ns) on Windows 7. It depends maybe on the hardware clock, I don't know. Anyway, whenever possible, we should avoid precision loss of a clock.

----------
components: Interpreter Core
files: round.py
messages: 304239
nosy: haypo
priority: normal
severity: normal
status: open
title: Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47217/round.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:17:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 14:17:18 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507817838.18.0.213398074469.issue28647@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

stdin is mentioned in the documentation of the -u option only due to weird internal buffering in Python 2, because user can expect that -u disables it. It is documented what methods use internal buffering and how get rid of it. No other buffering is mentioned.

This no longer actual in Python 3. I think there is no need to mention stdin in the context of the -u option at all. -u doesn't affect stdin buffering, whatever that would mean. Period.

Alternatively you can include a lecture about different kinds of buffering and how -u doesn't affect them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:17:19 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 12 Oct 2017 14:17:19 +0000
Subject: [issue31774] tarfile.open ignores custom bufsize value when creating
 a new archive
Message-ID: <1507817839.86.0.213398074469.issue31774@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Trying to create an archive with the tarfile module, by specifying a different blocking factor, doesn't seem to work as only the default value is being used. The issue is reproducible on all the active python branches.

Attaching a script to reproduce it.

Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1492157

----------
components: Library (Lib)
files: tartest.py
messages: 304241
nosy: cstratak, lars.gustaebel
priority: normal
severity: normal
status: open
title: tarfile.open ignores custom bufsize value when creating a new archive
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47218/tartest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31774>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:37:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 14:37:59 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1507819079.77.0.213398074469.issue31773@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3943
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:38:09 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 14:38:09 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507819089.6.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> -u doesn't affect stdin buffering, whatever that would mean.

I think we need to document behavior of stdin somewhere, because current the sys.stdin documentation states:

> When interactive, standard streams are line-buffered. Otherwise, they
> are block-buffered like regular text files. You can override this value
> with the -u command-line option.

https://docs.python.org/3/library/sys.html#sys.stdin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:39:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 14:39:03 +0000
Subject: [issue31490] assertion failure in ctypes in case an _anonymous_ attr
 appears outside _fields_
In-Reply-To: <1505555858.95.0.114491369101.issue31490@psf.upfronthosting.co.za>
Message-ID: <1507819143.71.0.213398074469.issue31490@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fb3bb8d5d5d70acaaa0fdec15c137544fdd4463f by Serhiy Storchaka (Oren Milman) in branch '2.7':
[2.7] bpo-31490: Fix an assertion failure in ctypes in case an _anonymous_ attr is defined only outside _fields_. (GH-3615) (#3952)
https://github.com/python/cpython/commit/fb3bb8d5d5d70acaaa0fdec15c137544fdd4463f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31490>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:39:45 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 12 Oct 2017 14:39:45 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507819185.9.0.213398074469.issue31567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset 0e61e67a57deb4abc677808201d7cf3c38138e02 by ?ric Araujo (Daisuke Miyakawa) in branch 'master':
bpo-31567: add or fix decorator markup in docs (#3959)
https://github.com/python/cpython/commit/0e61e67a57deb4abc677808201d7cf3c38138e02


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:40:40 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Oct 2017 14:40:40 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507819240.23.0.213398074469.issue31567@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3944

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:41:24 2017
From: report at bugs.python.org (Denis Osipov)
Date: Thu, 12 Oct 2017 14:41:24 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507819284.42.0.213398074469.issue31761@psf.upfronthosting.co.za>


Denis Osipov <osipov_d at list.ru> added the comment:

Got it. Thank you for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:48:33 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 14:48:33 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507819713.32.0.213398074469.issue31567@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Use of classmethod and staticmethod decorators as functions is still a valid use case. I think the old signatures should be kept. It should be possible to document both uses in same place:

    .. function:: classmethod(function)
    .. decorator:: classmethod

       Documentation body.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:51:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 14:51:47 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507819907.56.0.213398074469.issue24084@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Victor. This change likely breaks graphical viewers of pstat data.

How gprof and similar tools solve the problem of outputting sub-microsecond timings?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:52:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 14:52:35 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507819955.91.0.213398074469.issue24084@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg304247

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:52:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 14:52:51 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507819971.59.0.213398074469.issue24084@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Victor. This change likely breaks graphical viewers of pstat data.

How gprof and similar tools solve the problem of outputting sub-millisecond timings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Thu Oct 12 10:58:05 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 14:58:05 +0000
Subject: [issue24084] pstats: sub-millisecond display
In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za>
Message-ID: <1507820285.34.0.213398074469.issue24084@psf.upfronthosting.co.za>


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

> I concur with Victor. This change likely breaks graphical viewers of pstat data.

I propose to *do* break the format by always displaying percall timings with a precision of 6 digits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24084>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:02:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 15:02:42 +0000
Subject: [issue31490] assertion failure in ctypes in case an _anonymous_ attr
 appears outside _fields_
In-Reply-To: <1505555858.95.0.114491369101.issue31490@psf.upfronthosting.co.za>
Message-ID: <1507820562.92.0.213398074469.issue31490@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31490>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:09:32 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:09:32 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
Message-ID: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>


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

It seems like that some methods of the io.TextIOWrapper class requires that its buffer object has the read1() method, whereas the constructor checks if the buffer has a read1() method and the TextIOWrapper _read_chunk() method is able to call buffer.read() if buffer doesn't have read1().

This issue may help to get fully unbuffered sys.stdin, at least when replaced manually:

stdin = sys.stdin
sys.stdin = open(0, "r", buffering=0, encoding=stdin.encoding, errors=stdin.errors, newline=stdin.newline)

----------
components: IO
messages: 304250
nosy: haypo
priority: normal
severity: normal
status: open
title: Support unbuffered TextIOWrapper
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:09:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:09:53 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507820993.78.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

Interesting comment in create_stdio() of Python/pylifecycle.c:
---
    /* stdin is always opened in buffered mode, first because it shouldn't
       make a difference in common use cases, second because TextIOWrapper
       depends on the presence of a read1() method which only exists on
       buffered streams.
    */
    if (Py_UnbufferedStdioFlag && write_mode)
        buffering = 0;
    else
        buffering = -1;
---

stdin is always buffered ;-)

I created bpo-31775: "Support unbuffered TextIOWrapper".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:10:13 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 12 Oct 2017 15:10:13 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507821013.21.0.213398074469.issue31567@psf.upfronthosting.co.za>


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


----------
pull_requests: +3945

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:12:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:12:26 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1507821146.3.0.213398074469.issue31775@psf.upfronthosting.co.za>


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

I created this issue because of this comment in create_stdio() of Python/pylifecycle.c:
---
    /* stdin is always opened in buffered mode, first because it shouldn't
       make a difference in common use cases, second because TextIOWrapper
       depends on the presence of a read1() method which only exists on
       buffered streams.
    */
    if (Py_UnbufferedStdioFlag && write_mode)
        buffering = 0;
    else
        buffering = -1;
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:25:04 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:25:04 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1507821904.61.0.213398074469.issue31775@psf.upfronthosting.co.za>


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

Oh, currently it's not possible to create an unbuffered read-only TextIOWrapper object:

haypo at selma$ python3
Python 3.6.2 (default, Oct  2 2017, 16:51:32) 
>>> open("/etc/issue", "r", 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: can't have unbuffered text I/O

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:25:09 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 12 Oct 2017 15:25:09 +0000
Subject: [issue31767] Windows Installer fails with error 0x80091007 when
 trying to install debugging symbols
In-Reply-To: <1507756995.05.0.213398074469.issue31767@psf.upfronthosting.co.za>
Message-ID: <1507821909.7.0.213398074469.issue31767@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Can you try moving the installer exe to its own (empty) directory before running it?

The correct file is on the server (I just redownloaded and verified), so the most likely cause is that you ran a /layout at some point in the past and are getting that file locally. As you saw in the log, we will look in the directory the installer is launched from for a matching local file, so that it's possible to download all the optional components and then do a full install while offline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:26:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:26:34 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507821994.28.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

Serhiy: "I think there is no need to mention stdin in the context of the -u option at all. -u doesn't affect stdin buffering, whatever that would mean. Period."

Hum, I propose to mention stdin in -u documentation as: "The option has no effect on stdin." What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:27:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:27:40 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507822060.56.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

> I think we need to document behavior of stdin somewhere, because current the sys.stdin documentation states:
>
>> When interactive, standard streams are line-buffered. Otherwise, they
>> are block-buffered like regular text files. You can override this value
>> with the -u command-line option.

The last sentence is wrong and should be removed from sys.stdin documentation, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:29:25 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 12 Oct 2017 15:29:25 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507822165.67.0.213398074469.issue31567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think existing uses of the decorator markup rely on the reader?s understanding that it?s syntactic sugar for a call and an assignment, and they don?t have decorator+function markup.  The PRs for this ticket follow that.

That said, staticmethod as a non-decorator has an important use case for function injection in tests (using self.func in TestCase classes that work with a C module and an equivalent Python version).  Maybe this deserves an extra example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:30:50 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 15:30:50 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1507822250.74.0.213398074469.issue31775@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The falling back to read() was implemented in issue12591. What methods still require read1()?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:40:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 15:40:39 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507822839.42.0.213398074469.issue28647@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Hum, I propose to mention stdin in -u documentation as: "The option has no effect on stdin." What do you think?

This LGTM too. More precise, it has no effect on stdin buffering. It has effect on the line_buffering attribute, but this attribute has no effect on reading.

> The last sentence is wrong and should be removed from sys.stdin documentation, no?

Or correct it, making it related only to stdout and stderr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:46:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:46:21 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1507823181.83.0.213398074469.issue31775@psf.upfronthosting.co.za>


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

> The falling back to read() was implemented in issue12591. What methods still require read1()?

I read the Python implementation of TextIOWrapper in _pyio:

* seek() calls buffer.read() "if chars_to_skip:"... not sure that it can happen if buffer is a FileIO?
* read(None)  and read(-1) to read "everything" (until EOF): buffer.read()

It seems like read(None) also calls buffer.read() in the C implementation, _io_TextIOWrapper_read_impl():

        /* Read everything */
        PyObject *bytes = _PyObject_CallMethodId(self->buffer, &PyId_read, NULL);
        PyObject *decoded;
        if (bytes == NULL)
            goto fail;

and in _io_TextIOWrapper_seek_impl():

        /* Just like _read_chunk, feed the decoder and save a snapshot. */
        PyObject *input_chunk = _PyObject_CallMethodId(
            self->buffer, &PyId_read, "i", cookie.bytes_to_feed);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:46:54 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Oct 2017 15:46:54 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507823214.33.0.213398074469.issue31567@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> That said, staticmethod as a non-decorator has an important use case for
> function injection in tests (using self.func in TestCase classes that work with
> a C module and an equivalent Python version).  Maybe this deserves an extra
> example?

Yes, that would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:48:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:48:40 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1507823320.96.0.213398074469.issue31775@psf.upfronthosting.co.za>


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

Context: I created this issue as a follow-up of the discussion on the -u command line option, bpo-28647, which still leaves sys.stdin *buffered* in the current master branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:51:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:51:58 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1507823518.3.0.213398074469.issue31773@psf.upfronthosting.co.za>


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


New changeset cba9a0c6def70549046f1afa6a80e38fe706520e by Victor Stinner in branch 'master':
bpo-31773: time.perf_counter() uses again double (GH-3964)
https://github.com/python/cpython/commit/cba9a0c6def70549046f1afa6a80e38fe706520e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:52:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:52:16 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1507823536.14.0.213398074469.issue31773@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Thu Oct 12 11:53:43 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Oct 2017 15:53:43 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1507823623.33.0.213398074469.issue31415@psf.upfronthosting.co.za>


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

Ok, the feature was implemented, the Windows clock resolution was fixed as well. It's time to close this issue.

If you still have concerns about import time, see open discussions on the python-dev mailing list, or open new issues ;-)

Thanks again Naoki INADA for this nice and useful feature!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Thu Oct 12 12:17:07 2017
From: report at bugs.python.org (Matthew Patton)
Date: Thu, 12 Oct 2017 16:17:07 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507825027.28.0.213398074469.issue30767@psf.upfronthosting.co.za>


Matthew Patton <pattonme at yahoo.com> added the comment:

I believe this diff addresses the failure of formatException() to check it's parameter's datatype. I still maintain this should be re-opened since it's guaranteed to raise an exception when someone sets 'exc_info=TruthyValue' in kwargs. albeit with a more focused PR.


diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py
index 00a022039d..5c61cd56a1 100644
--- a/Lib/logging/__init__.py
+++ b/Lib/logging/__init__.py
@@ -533,6 +533,8 @@ class Formatter(object):
         This default implementation just uses
         traceback.print_exception()
         """
+        if not isinstance(ei, tuple) or ei[0] is None:
+            return ""
         sio = io.StringIO()
         tb = ei[2]
         # See issues #9427, #1553375. Commented out for now.
@@ -584,9 +586,7 @@ class Formatter(object):
         if self.usesTime():
             record.asctime = self.formatTime(record, self.datefmt)
         s = self.formatMessage(record)
-        if (isinstance(record.exc_info, tuple) and record.exc_info[0]):
-            # Intercept 'Boolean' - causes subscript error if passed to formatException,
-            # and empty Tuples which emit 'NoneType None' into message.
+        if record.exc_info:
             # Cache the traceback text to avoid converting it multiple times
             # (it's constant anyway)
             if not record.exc_text:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 12:19:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 16:19:18 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1507825158.57.0.213398074469.issue31775@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What methods still require read1()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Thu Oct 12 12:26:25 2017
From: report at bugs.python.org (Oren Milman)
Date: Thu, 12 Oct 2017 16:26:25 +0000
Subject: [issue31770] crash and refleaks when calling
 sqlite3.Cursor.__init__() more than once
In-Reply-To: <1507796316.87.0.213398074469.issue31770@psf.upfronthosting.co.za>
Message-ID: <1507825585.96.0.213398074469.issue31770@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3946
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31770>
_______________________________________

From report at bugs.python.org  Thu Oct 12 12:28:59 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 12 Oct 2017 16:28:59 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507825739.13.0.213398074469.issue31567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset 03b9537dc515d10528f83c920d38910b95755aff by ?ric Araujo in branch 'master':
bpo-31567: more decorator markup fixes in docs (GH-3959) (#3966)
https://github.com/python/cpython/commit/03b9537dc515d10528f83c920d38910b95755aff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 12:33:07 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 12 Oct 2017 16:33:07 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507825987.6.0.213398074469.issue31567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset 205dd4e14de77f9c8ed2903ddebbcf9968bbb6a9 by ?ric Araujo (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31567: add or fix decorator markup in docs (GH-3959) (GH-3966)
https://github.com/python/cpython/commit/205dd4e14de77f9c8ed2903ddebbcf9968bbb6a9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 12:34:21 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 12 Oct 2017 16:34:21 +0000
Subject: [issue31567] Inconsistent documentation around decorators
In-Reply-To: <1506238290.29.0.485453330645.issue31567@psf.upfronthosting.co.za>
Message-ID: <1507826061.21.0.213398074469.issue31567@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Cheers!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31567>
_______________________________________

From report at bugs.python.org  Thu Oct 12 13:10:46 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 12 Oct 2017 17:10:46 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507828246.53.0.213398074469.issue31761@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Closing this issue, I opened https://github.com/python/devguide/issues/280 so that Dev Guide can be updated.

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 13:39:57 2017
From: report at bugs.python.org (Anthony Flury)
Date: Thu, 12 Oct 2017 17:39:57 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507829997.48.0.213398074469.issue31766@psf.upfronthosting.co.za>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

Isn't Python 2.7 in Security Fix only as well ?

It seems strange; Python 3.5 probably the most heavily installed Python 3 release (every Ubuntu installation has Python 3.5 installed by default - and neither Python 3.6 or 3.7 are available from the standard ubuntu repository); the docs.python.org site is the normal place people are directed to for help - and the implication of the removal will be for many people is that Python 3.5 is obsolete which isn't the case at all.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 13:43:27 2017
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 12 Oct 2017 17:43:27 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507830207.45.0.213398074469.issue31766@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

The 3.5 docs should really remain in the main docs UI via the pulldown as long as it's so widely used.  The fact that it won't be changing much just means it can be served efficiently.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 13:49:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 17:49:05 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507830545.39.0.213398074469.issue31761@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See issue25588. Currently running tests from IDLE doesn't work, but it worked in the past and maybe we can make it working again.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:04:19 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:04:19 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507831459.85.0.213398074469.issue31766@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +3947
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:05:31 2017
From: report at bugs.python.org (Matthew Patton)
Date: Thu, 12 Oct 2017 18:05:31 +0000
Subject: [issue31763] Add NOTICE level to the logging module
In-Reply-To: <1507747705.55.0.213398074469.issue31763@psf.upfronthosting.co.za>
Message-ID: <1507831531.1.0.213398074469.issue31763@psf.upfronthosting.co.za>


Matthew Patton <pattonme at yahoo.com> added the comment:

syslog(3) is cited in the code as inspiration and has been the goto definition for logging levels for 40 years across many, many projects. NOTICE is incredibly useful especially to those of us who are sysadmins.

Why would Python not implement the full suite of syslog levels? Admittedly the case for ALERT and EMERGENCY might be a stretch. It at least doesn't hobble those who want to use them. Without proper coverage one has to settle for unnecessary jumbling of Noteworthy items being buried in the torrent of Informational but not really interesting items.

eg. INFO for attempting a connection. NOTICE for temporary service unavailability or handshake timeout, WARNING (maybe ERROR) for retry exhausted depending on what the failure means to the app.

eg. INFO for login attempts. NOTICE for password expiry date approaching, for failed logins (bad username/passwords, locked/expired account), for password change attempts, for temporary Federated Auth connect failure. None of which rise to the level of WARNING.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31763>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:08:45 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:08:45 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507831725.8.0.213398074469.issue31766@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset b7cbfe49e39a7bbd7da20b937735a8a60bbf1872 by Ned Deily in branch 'master':
bpo-31766: restore 3.5 to docs version switchers (#3969)
https://github.com/python/cpython/commit/b7cbfe49e39a7bbd7da20b937735a8a60bbf1872


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:12:22 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:12:22 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507831942.3.0.213398074469.issue31766@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +3948

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:19:09 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:19:09 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507832349.46.0.213398074469.issue31766@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset f8d42ea0e4341b270f1de71b4ff40cfa18420eed by Ned Deily in branch '3.6':
bpo-31766: restore 3.5 to docs version switchers (#3970)
https://github.com/python/cpython/commit/f8d42ea0e4341b270f1de71b4ff40cfa18420eed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:20:47 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:20:47 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507832447.15.0.213398074469.issue31766@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +3949

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:24:25 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:24:25 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507832665.54.0.213398074469.issue31766@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 356b68023d6fee5e30d25a4a680ac5b9e4f8dd65 by Ned Deily in branch '2.7':
bpo-31766: restore 3.5 to docs version switchers (#3971)
https://github.com/python/cpython/commit/356b68023d6fee5e30d25a4a680ac5b9e4f8dd65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:31:21 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 18:31:21 +0000
Subject: [issue31766] Python 3.5 missing from documentation
In-Reply-To: <1507756717.96.0.213398074469.issue31766@psf.upfronthosting.co.za>
Message-ID: <1507833081.1.0.213398074469.issue31766@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

> Isn't Python 2.7 in Security Fix only as well ?

No, 2.7 is still being actively maintained (until 2020).
(https://devguide.python.org/#status-of-python-branches)

But, bowing to popular demand, I've restored 3.5 to the switchers for 3.7, 3.6, and 2.7.  It should appear again in the on-line docs shortly.  Thanks for all of your comments!

----------
resolution: not a bug -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31766>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:32:32 2017
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Oct 2017 18:32:32 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507833152.53.0.213398074469.issue31772@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The problem with that is it will increase the number of stat calls which we have always tried to minimize due to performance worries.

https://www.python.org/dev/peps/pep-0552/ has also been accepted which will take care of this specific case. So while I appreciate the work on this, Devin, I'm going to close this in favour of people who have this problem to use deterministic .pyc files instead.

----------
nosy: +brett.cannon, eric.snow, ncoghlan
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:53:00 2017
From: report at bugs.python.org (Igor Skochinsky)
Date: Thu, 12 Oct 2017 18:53:00 +0000
Subject: [issue31767] Windows Installer fails with error 0x80091007 when
 trying to install debugging symbols
In-Reply-To: <1507821909.7.0.213398074469.issue31767@psf.upfronthosting.co.za>
Message-ID: <CACq7zKnq+g_Ohvyc-2OPOdSRAG4NrdQ+pbP3MF7LQKS53QDbig@mail.gmail.com>


Igor Skochinsky <skochinsky at gmail.com> added the comment:

Hi Steve,

 Thanks for the suggestion! I tried that and while it did not succeed it
gave me an idea of what went wrong last time since it complained about lack
of disk space. I have *not* run the /layout but now that I checked I indeed
had core_d.msi and core_pdb.msi (and a few more) in the Downloads
directory, so I think maybe the installer tried to download them but ran
out of space and the download was incomplete.

Another possibility is that the .msi was for the wrong installer - I first
tried installing the x86 version but later changed my mind but since I did
not expect it to download extra files into the same directory I did not
clean them. Also it seems the downloaded .msi files have the original
timestamp (16-09-27) so I did not notice them when sorting my downloads by
date until I tried to look for .msi files specifically.

In the end I guess this could be closed as PEBKAC but I think maybe some
more testing in low-disk-space conditions and/or installing x86 then x64
from the same directory could uncover some real issues.

In general, I found the 3.3 install experience not very straightforward
compared to 2.7 - I expected that the installer contains everything
necessary (since I did *not* pick "webinstall" one) and won't download
extra files (with the exception of the PDB option which did say
"download"). If the .msi files came from the .exe itself, I'd expect them
to be extracted into a unique temporary directory and not next to the exe.

I will work on freeing some space and then try again.

> Steve Dower <steve.dower at python.org> added the comment:
>
> Can you try moving the installer exe to its own (empty) directory before
> running it?
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 14:56:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 18:56:00 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507834560.33.0.213398074469.issue30058@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have tested it on FreeBSD, found and fixed one bug.

----------
assignee:  -> serhiy.storchaka
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 15:13:50 2017
From: report at bugs.python.org (Matthew Patton)
Date: Thu, 12 Oct 2017 19:13:50 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507835630.48.0.213398074469.issue30767@psf.upfronthosting.co.za>


Change by Matthew Patton <pattonme at yahoo.com>:


----------
pull_requests: +3950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 15:17:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 19:17:48 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507835868.66.0.213398074469.issue30058@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset de072100775cc29e6cd93a75466cecbd1086f258 by Serhiy Storchaka in branch 'master':
bpo-30058: Fixed buffer overflow in select.kqueue.control(). (#1095)
https://github.com/python/cpython/commit/de072100775cc29e6cd93a75466cecbd1086f258


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 15:19:00 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Oct 2017 19:19:00 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507835940.11.0.213398074469.issue30058@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +3951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 15:19:21 2017
From: report at bugs.python.org (paul j3)
Date: Thu, 12 Oct 2017 19:19:21 +0000
Subject: [issue31640] Document exit() from parse_args
In-Reply-To: <1506704042.9.0.213398074469.issue31640@psf.upfronthosting.co.za>
Message-ID: <1507835961.61.0.213398074469.issue31640@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

And the actual exit is via `parse.error` and `parse.exit`, which are documented in 16.4.5.9.

When run interactively in Ipython, exits (including the help) are captured and displayed with:

In [896]: parser.parse_args()
usage: ipython3 [-h] [--one | --two | --six]
ipython3: error: unrecognized arguments: --pylab --nosep --term-title --InteractiveShellApp.pylab_import_all=False
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2

The exit makes unittesting a challenge.  'test_argparse.py' resolves this by using a subclassed parser, one that changes the error/exit, and also redirects output.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31640>
_______________________________________

From report at bugs.python.org  Thu Oct 12 15:35:14 2017
From: report at bugs.python.org (Catalin Patulea)
Date: Thu, 12 Oct 2017 19:35:14 +0000
Subject: [issue14976] queue.Queue() is not reentrant,
 so signals and GC can cause deadlocks
In-Reply-To: <1338540186.86.0.989988943379.issue14976@psf.upfronthosting.co.za>
Message-ID: <1507836914.62.0.213398074469.issue14976@psf.upfronthosting.co.za>


Change by Catalin Patulea <cronos586 at gmail.com>:


----------
nosy: +Catalin Patulea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14976>
_______________________________________

From report at bugs.python.org  Thu Oct 12 15:48:11 2017
From: report at bugs.python.org (paul j3)
Date: Thu, 12 Oct 2017 19:48:11 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507837691.95.0.213398074469.issue31768@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

As documented in many other issues, the usage formatter is brittle.  It formats the individual usages, joins them into a string. Then if too long to fit on one line it tries t split into actions, etc.  This split produces an assertion error if there are 'wierd' characters in the names (e.g. #[]).

With mutually exclusive groups it gets even worse.  The brackets and | are spliced into the original string, and then excess [] and spaces are removed.  Once recent issue complained about its handling of nested groups (which are borderline wrong).

So I"m not surprised that a long group that spans a couple of lines gets messed up.   It requires a major rewrite, and even then I there will be formats involving groups that fall through the cracks.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Thu Oct 12 16:04:58 2017
From: report at bugs.python.org (Devin Bayer)
Date: Thu, 12 Oct 2017 20:04:58 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507838698.38.0.213398074469.issue31772@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

Hello Brett, it would be nice if you would discuss this before closing. The referenced PEP will not solve my use case, because hash-based checking will not become the default.

The issue is that by default the source file loader will be returning stale bytecode and that's incorrect behavior.

If you wish to avoid the stat call you could use a higher resolution timestamp in the pyc file, or better yet add a second field indicating bytecode compilation time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Thu Oct 12 16:20:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 20:20:04 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507839604.19.0.213398074469.issue30058@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3952

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 16:20:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 20:20:46 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507839646.24.0.213398074469.issue30058@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c923da188bc055e4f3001a6daf1caf54f2b10e40 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-30058: Fixed buffer overflow in select.kqueue.control(). (GH-1095) (#3973)
https://github.com/python/cpython/commit/c923da188bc055e4f3001a6daf1caf54f2b10e40


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 16:52:05 2017
From: report at bugs.python.org (paul j3)
Date: Thu, 12 Oct 2017 20:52:05 +0000
Subject: [issue31768] argparse drops '|'s when the arguments are too long
In-Reply-To: <1507758565.64.0.213398074469.issue31768@psf.upfronthosting.co.za>
Message-ID: <1507841525.4.0.213398074469.issue31768@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

I've changed your example a bit to clarify some points.

    parser.add_argument('n', type=int)
    group = parser.add_mutually_exclusive_group()
    group.add_argument("-v", "--verbose", action="store_true")
    group.add_argument("-q", "--quiet", action="store_true")
    group.add_argument("-x", metavar='X', type=str, help="the base", nargs='?')
    group.add_argument("-y", metavar='Y', type=str, help="the exponent", nargs='?')

    for i in range(int(sys.argv[1])):
         group.add_argument("z%s"%i, nargs='?')

With `n=0`, usage is:

    usage: PROG [-h] [-v | -q | -x [X] | -y [Y]] n

Notice that the positional is placed last.  That is, regardless of the definition order, 'usage' shows optionals first, positionals last.

With 2 'z':

    usage: PROG [-h] [-v] [-q] [-x [X]] [-y [Y]] n [z0] [z1]

All the mutually exclusive markings have been dropped.  That's because the component actions are not consecutive, having been split up by the reordering of positionals.  Marking the group is done only if it can do so in a simple minded way.  The group testing is not dependent on being able to format it.  That's done by a different part of the code.

For 7 'z' it splits the line.  Positionals are printed on a new line.

    usage: PROG [-h] [-v] [-q] [-x [X]] [-y [Y]]
                n [z0] [z1] [z2] [z3] [z4] [z5] [z6]


I noticed this problem with formating group positional in multiline usage some time ago, https://bugs.python.org/issue10984#msg192954


Another thing to watch out for - multiple positionals in a group don't make sense.  Only the first one can ever be filled.  I don't see a formal check, but it doesn't make logical sense.

If I change the code so it produces multiple optionals:

    usage: PROG [-h] [-v | -q | -x X | -y Y | --z0 [Z0] | --z1 [Z1] | --z2 [Z2] |
                --z3 [Z3] | --z4 [Z4]]
                n

the group markings are preserved across lines.  Note again that the positional (n) is on its own line.

---

Here's another weird behavior, with just one positional in the group:

    1314:~/mypy$ python3 argdev/issue31768.py 1 -v 3
    usage: PROG [-h] [-v] [-q] [-x X] [-y Y] n [z0]
    PROG: error: unrecognized arguments: 3

It complains about not recognizing the '3', rather than complaining about 'z0' not allow with '-v'.  That's because the '?' has already been satisfied with [] when parsing the 'n' (see https://bugs.python.org/issue15112).

---

In sum, I think this is pathological case that doesn't need to be fixed.  

Usage is ok if there's a long list of optionals.  Usage (and parsing) with just one positional in the group is brittle.  We shouldn't expect it work with many positionals in the group.

---

@Louie, you 2nd example interweaves the definitions of two groups.  Except for the optionals/positions reordering that I mentioned above, usage does not reorder arguments.  Mutually exclusive groups are marked only if they are contiguous.  

https://bugs.python.org/issue10984 has a patch that can format groups even if the actions don't occur in the right order.  It isn't a trivial fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31768>
_______________________________________

From report at bugs.python.org  Thu Oct 12 16:59:28 2017
From: report at bugs.python.org (Pablo)
Date: Thu, 12 Oct 2017 20:59:28 +0000
Subject: [issue31776] Inconsistent exception chaining in
 /Lib/xml/etree/ElementPath.py
Message-ID: <1507841968.12.0.213398074469.issue31776@psf.upfronthosting.co.za>


New submission from Pablo <pablogsal at gmail.com>:

Based on bpo-29762 (https://github.com/python/cpython/commit/5affd23e6f42125998724787025080a24839266e), there is an inconsistency on one exception chain in /Lib/xml/etree/ElementPath.py:

             try:
                 selector.append(ops[token[0]](next, token))
             except StopIteration:
                raise SyntaxError("invalid path")

should be

              raise SyntaxError("invalid path") from None

----------
components: Library (Lib)
messages: 304288
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Inconsistent exception chaining in /Lib/xml/etree/ElementPath.py
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31776>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:00:00 2017
From: report at bugs.python.org (Pablo)
Date: Thu, 12 Oct 2017 21:00:00 +0000
Subject: [issue31776] Missing "raise from None" in
 /Lib/xml/etree/ElementPath.py
In-Reply-To: <1507841968.12.0.213398074469.issue31776@psf.upfronthosting.co.za>
Message-ID: <1507842000.84.0.213398074469.issue31776@psf.upfronthosting.co.za>


Change by Pablo <pablogsal at gmail.com>:


----------
title: Inconsistent exception chaining in /Lib/xml/etree/ElementPath.py -> Missing "raise from None" in /Lib/xml/etree/ElementPath.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31776>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:02:42 2017
From: report at bugs.python.org (Pablo)
Date: Thu, 12 Oct 2017 21:02:42 +0000
Subject: [issue31776] Missing "raise from None" in
 /Lib/xml/etree/ElementPath.py
In-Reply-To: <1507841968.12.0.213398074469.issue31776@psf.upfronthosting.co.za>
Message-ID: <1507842162.09.0.213398074469.issue31776@psf.upfronthosting.co.za>


Change by Pablo <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +3953
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31776>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:02:42 2017
From: report at bugs.python.org (Pablo)
Date: Thu, 12 Oct 2017 21:02:42 +0000
Subject: [issue29762] Use "raise from None"
In-Reply-To: <1489007676.29.0.138385616596.issue29762@psf.upfronthosting.co.za>
Message-ID: <1507842162.18.0.00913614298617.issue29762@psf.upfronthosting.co.za>


Change by Pablo <pablogsal at gmail.com>:


----------
pull_requests: +3954

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29762>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:13:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 21:13:13 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507842793.61.0.213398074469.issue30058@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9aa60245a0ff929e528b4521da7af20dacd4145b by Serhiy Storchaka in branch '2.7':
[2.7] bpo-30058: Fixed buffer overflow in select.kqueue.control(). (GH-1095). (#3976)
https://github.com/python/cpython/commit/9aa60245a0ff929e528b4521da7af20dacd4145b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:13:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Oct 2017 21:13:33 +0000
Subject: [issue30058] Buffer overflow in kqueue.control()
In-Reply-To: <1492017218.53.0.767201958064.issue30058@psf.upfronthosting.co.za>
Message-ID: <1507842813.18.0.213398074469.issue30058@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30058>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:24:30 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Oct 2017 21:24:30 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507843470.68.0.213398074469.issue31742@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:45:20 2017
From: report at bugs.python.org (Antoine Pietri)
Date: Thu, 12 Oct 2017 21:45:20 +0000
Subject: [issue22674] strsignal() missing from signal module
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1507844720.44.0.213398074469.issue22674@psf.upfronthosting.co.za>


Antoine Pietri <antoine.pietri1 at gmail.com> added the comment:

Hey everyone,

We would like to have that feature for a project where we have to use ctypes to achieve that. I don't know the answers to vajrasky's questions but I just wanted to chime in to say having this feature would be greatly appreciated. I can also work on the code if you need any help.

Thanks!

----------
nosy: +antoine.pietri

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Thu Oct 12 17:47:12 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 12 Oct 2017 21:47:12 +0000
Subject: [issue31767] Windows Installer fails with error 0x80091007 when
 trying to install debugging symbols
In-Reply-To: <1507756995.05.0.213398074469.issue31767@psf.upfronthosting.co.za>
Message-ID: <1507844832.58.0.213398074469.issue31767@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

FWIW, all your assumptions about how it should work are correct. If you don't know how the files got there instead of a randomly generated temporary path, then I don't know either. /layout is the only time we download anything to a non-temp directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31767>
_______________________________________

From report at bugs.python.org  Thu Oct 12 18:07:23 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Oct 2017 22:07:23 +0000
Subject: [issue31777] IDLE: Let users add to font selection
Message-ID: <1507846043.1.0.213398074469.issue31777@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Config dialog Font tab has a sample box.  It currently only contains Ascii chars.  #13802 will add characters from extended latin1 and several other character sets.  But we cannot show everything.  Hence a spinoff proposal: let users augment the sample with things of particular interest.  (There are multiple variations of this idea, which I defer to another post.)

----------
assignee: terry.reedy
components: IDLE
messages: 304292
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Let users add to font selection
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31777>
_______________________________________

From report at bugs.python.org  Thu Oct 12 18:08:19 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Oct 2017 22:08:19 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1507846099.45.0.213398074469.issue13802@psf.upfronthosting.co.za>


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

I pushed new commits to the PR that changed the Korean, Japanese, and Indian samples and the help message.

Korea: The line is now the first 10 chars of Dong-hee Na's suggestion.  Thank you for helping (and Louie for the cc).

Japan: The line is now the hiragana and katakana versions of the 5 vowels.  As far as I know, 'kanji' are a subset of CJK 'hanzi', with different pronunciations and possibly different meanings, so I see no need for any here.

India: The second line is now Tamil digits and vowels.

China: I found the chars, with translation, including the one simplified/traditional pair, on Wikipedia.  I did not know if more pairs would be a good idea or not, and I do not know of others.  Louie, if you have a better idea, please post it (with translation ;-).

Dialog size: The height is about 710 pixels, 10% larger than before the additions to the General page a month ago.  So it was previously too tall for 800 x 600 and still fits 1024 x 768.  Further expansion should mostly be in width, but there is some vertical room.

Spaces and labels: I initially had neither.  I could hardly stand to look.  The label are needed for people who do not recognize the character sets, and I use them to make three general points in the help entry: tk uses whatever font it can to cover most of the BMP; fixed font sizes for Latin font only apply to Latin chars; and right-to-left is handled correctly.

Latin1: I consider the Windows fontchooser to be an anti-model for this issue in that it is limited to alphabetic characters and confuses 'language' with 'character set'.  Western, Central European, Baltic, Turkish, and Vietnamese languages all use latin characters.  The non-ascii, decorated versions are 'covered' by the non-ascii Latin1 line.  ? is already present. ? is intended to represent all circumflexed characters, including ?. I intended the repeated use of A as base character to imply that.  I not sure if using a different base for each decoration would be better.  Similarly, ? covers ?.  I am thinking about using fewer symbols and more alphabetic characters.  It might be a good idea to add something, such as ?, from the Extended block, beyond \u00ff.

User additions: This would be a separate issue, see #31777.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Thu Oct 12 18:31:18 2017
From: report at bugs.python.org (David Bieber)
Date: Thu, 12 Oct 2017 22:31:18 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
Message-ID: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>


New submission from David Bieber <dbieber at google.com>:

# Overview
ast.literal_eval supports some non-literals in Python 3.
The behavior of this function runs contrary to the documented behavior.


# The Issue
The [documentation](https://docs.python.org/3/library/ast.html#ast.literal_eval) says of the function "It is not capable of evaluating arbitrarily complex expressions, for example involving operators or indexing."

However, literal_eval is capable of evaluating expressions with certain operators, particular the operators "+" and "-".

As has been explained previously, the reason for this is to support "complex" literals such as 2+3j. However, this has unintended consequences which I believe to be indicative of a bug. Examples of the unintended consequences include `ast.literal_eval('1+1') == 2` `ast.literal_eval('2017-10-10') == 1997`. I would expect each of these calls to literal_eval to throw a ValueError, as the input string is not a literal. Instead, literal_eval successfully evaluates the input string, in the latter case giving an unexpected result (since the intent of the string is to represent a 21st century date.)

Since issue arose as a [Python Fire issue](https://github.com/google/python-fire/issues/97), where the behavior of Python Fire was unexpected for inputs such as those described above (1+1 and 2017-10-10) only in Python 3. For context, Python Fire is a CLI library which uses literal_eval as part of its command line argument parsing procedure.

I think the resolution to this issue is having literal_eval raise a ValueError if the ast of the input represents anything other than a Python literal, as described in the documentation. That is, "The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and None." Additional operations, such as the binary operations "+" and "-", unless they explicitly create a complex number, should produce a ValueError.

If that resolution is not the direction we take, I also would appreciate knowing if there is another built in approach for determining if a string or ast node represents a literal.


# Reproducing
The following code snippets produce different behaviors in Python 2 and Python 3.
```python
import ast
ast.literal_eval('1+1')
```

```python
import ast
ast.literal_eval('2017-10-10')
```


# References
- The Python Fire issue is here: https://github.com/google/python-fire/issues/97
- Prior discussion of a similar issue: https://bugs.python.org/issue22525
- I think is where complex number support was originally added: https://bugs.python.org/issue4907
- In this thread, https://bugs.python.org/issue24146, one commenter explains that literal_eval's support for "2+3" is an unintentional side effect of supporting complex literals.

----------
messages: 304294
nosy: David Bieber
priority: normal
severity: normal
status: open
title: ast.literal_eval supports non-literals in Python 3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Thu Oct 12 18:32:49 2017
From: report at bugs.python.org (David Bieber)
Date: Thu, 12 Oct 2017 22:32:49 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1507847569.78.0.213398074469.issue31778@psf.upfronthosting.co.za>


Change by David Bieber <dbieber at google.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Thu Oct 12 19:18:26 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Oct 2017 23:18:26 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507850306.31.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

Victor, what is your opinion of running 'from test import autotest' in a standard python shell window, opened from an icon, as opposed to IDLE's shell?

>  many tests fail just because of IDLE.

We cannot know what to blame on IDLE without a proper control experiment.  I updated my Win10 repository, rebuilt python 3.7, ran the tests from the command line, and all passed (thank you for making this routine).  I ran autotest in a Python console and saw a new resource warning from one of the async tests and 3 failures.  I cannot say what they were because when the test finished, the window closed (crashed), which is a metafailure.  I will rerun and try to identify the error as they occur.

Should we reopen this issue or open a new issue, to fix problems not due to IDLE, or remove the entire suggestion to use autotest, and remove autotest itself?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 19:42:43 2017
From: report at bugs.python.org (Pablo)
Date: Thu, 12 Oct 2017 23:42:43 +0000
Subject: [issue29696] Use namedtuple in string.Formatter.parse iterator
 response
In-Reply-To: <1488468843.51.0.704010418399.issue29696@psf.upfronthosting.co.za>
Message-ID: <1507851763.2.0.213398074469.issue29696@psf.upfronthosting.co.za>


Change by Pablo <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +3956
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29696>
_______________________________________

From report at bugs.python.org  Thu Oct 12 19:42:47 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Oct 2017 23:42:47 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507851767.03.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

0:00:28 [ 25/407] test_asyncio
F:\dev\3x\lib\asyncio\sslproto.py:330: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x066D38C0>
  source=self)

test_code_module - multiple errors

test test_importlib failed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_importlib\test_locks.py", line 134, in test_all_locks
    self.bootstrap._module_locks)
AssertionError: 0 != 1 : {'test.autotest': <weakref at 0x0395D620; to '_ModuleLock' at 0x03957E70>}

test_warnings failed - multiple errors

crash after summary printed.
I am rerunning in python started from command to see if there is any message printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 20:01:07 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Oct 2017 00:01:07 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507852867.72.0.213398074469.issue30744@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Wow, nothing here is simple. :-( Even though the examples show that there's obviously a bug, I would caution against fixing it rashly without understanding how the current behavior may be useful in other circumstances. I've lost what I recall from reading PEP 558 so I can't quite fathom the new design, but I wish you good luck trying to implement it, and hopefully it will work out as hoped for (simpler, solving the issue, keeping the useful behaviors).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Thu Oct 12 20:34:15 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 00:34:15 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507854855.23.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

The Python console exits because test.libregrtest.main.Regrtest._main calls sys.exit.  test.autotest consists of

from test.libregrtest import main
main()

The main call should be wrapped with try:...except sys.exit: pass

The output also has this variance from the command line result.

0:15:47 [319/407/2] test_subprocess
minkernel\crts\ucrt\src\appcrt\lowio\write.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN)
minkernel\crts\ucrt\src\appcrt\lowio\close.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN)
minkernel\crts\ucrt\src\appcrt\lowio\close.cpp(49) : Assertion failed: (_osfile(fh) & FOPEN)

The list of tests skipped seems to be the same.

By setting sys.argv before importing autotest, I got
======================================================================
FAIL: test_ps1 (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_code_module.py", line 35, in test_ps1
    self.assertEqual(self.sysmod.ps1, '>>> ')
AssertionError: <MagicMock name='sys.ps1' id='71914032'> != '>>> '

======================================================================
FAIL: test_ps2 (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_code_module.py", line 40, in test_ps2
    self.assertEqual(self.sysmod.ps2, '... ')
AssertionError: <MagicMock name='sys.ps2' id='72189080'> != '... '

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

======================================================================
FAIL: test_missing_filename_main_with_argv (test.test_warnings.CWarnTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_warnings\__init__.py", line 446, in test_missing_filename_main_with_argv
    self.assertEqual(w[-1].filename, sys.argv[0])
AssertionError: '__main__' != ''
- __main__
+

and

======================================================================
FAIL: test_missing_filename_main_with_argv (test.test_warnings.PyWarnTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_warnings\__init__.py", line 446, in test_missing_filename_main_with_argv
    self.assertEqual(w[-1].filename, sys.argv[0])
AssertionError: '__main__' != ''
- __main__

Wneh I start python with python.bat, sys.argv = [''], not ['__main__'].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 20:43:37 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Oct 2017 00:43:37 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507855417.3.0.213398074469.issue31742@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

OK, so the Django and Twisted developers had to resist some pressure from their users. These are mature projects and if they can't resist pressure from users something is wrong with those projects, and just pointing users to PEP 411 would have been a sufficient answer. (In reality of course, some users come across feeling excessively entitled, but that issue goes well beyond this.)

I recall what happened to cattrs (they came to our tracker: https://github.com/python/typing/issues/345). Ironically the cattrs package itself advertises itself as experimental, so this seems fair game. From skimming the issue they took it in stride (also, we fixed it in the next release).

I really don't think we should add annoying runtime behavior just to warn off to people who don't read the official docs. I don't actually know how that has to be done, but surely there are some Sphinx experts in the core-dev group?

Regarding the interpreters package, it feels like something of a different magnitude (due to the extensive interpreter changes and the implications for 3rd party extensions). But I really don't want this thread to be distracted by that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Thu Oct 12 21:05:01 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 01:05:01 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507856701.95.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

When I import autotest in IDLE's shell, test_code_module fails, test_importlib and test_warnings fail, as without IDLE, and test_gc and test_logging are new failures.  (Results are easy to see because SystemExit is caught and ignored.)

test test_gc failed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\support\__init__.py", line 1855, in wrapper
    return func(*args, **kwargs)
  File "F:\dev\3x\lib\test\test_gc.py", line 290, in test_get_count
    self.assertLess(a, 5)
AssertionError: 8 not less than 5

<a comes from gc.get_count() after gc.collect().  When I repeat outside of the test, a is 31.  I think either gc or this test is buggy.>


test test_logging failed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\test_logging.py", line 1960, in test_warnings
    "dummy.py:42: UserWarning: Explicit\n  Dummy line\n")
AssertionError: '\nWarning (from warnings module):\n  File[57 chars]it\n' != 'dummy.py:42: UserWarning: Explicit\n  Dummy line\n'
+ dummy.py:42: UserWarning: Explicit
- 
- Warning (from warnings module):
-   File "dummy.py", line 42
-     Dummy line
? --
+   Dummy line
- UserWarning: Explicit

IDLE replaces warnings.show_warnings.  In any case, there are 3 failures in Python's shell versus 4 in IDLE's shell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Thu Oct 12 21:21:47 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Oct 2017 01:21:47 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507857707.08.0.213398074469.issue31742@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Besides making the provisional warning more noticeable in module doc pages, perhaps we should have a "Provisional Package / API" section somewhere in the release's docset: a liat of all provisionals and perhaps a list of formerly provisional, now stable items that have transitioned since the previous feature release.  An obvious place would be in the What's New doc and it could be linked to from various places, like the Glossary, the release PEP, and/or the Release Notes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Thu Oct 12 21:27:30 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 01:27:30 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507858050.05.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If a proposed standard library API is sufficiently stable that the folks proposing it are reluctant to emit a runtime warning about any remaining stability risks, then I think it's reasonable to expect them to propose it as non-provisional and accept the related backwards compatibility obligations.

We have past examples of our being able to cope with that approach, such as when contextlib.nested turned out to be broken at a design level, so we deprecated it, removed it, and replaced it with a combination of contextlib.ExitStack and native support for multiple context managers in with statements.

Framing that in different terms: with PEP 411 as currently written, the benefits of instability accrue to the API publisher and willing early adopters, while the costs appear as negative externalities affecting folks that would prefer not to care about the API at all until it is covered by the regular backwards compatibility guarantees.

This RFE proposes to internalise some of those costs (in the form of a required runtime warning for any future provisional APIs), such that API publishers ask themselves "Do I *really* need this whole API to be provisional? Can I restructure it so only selected clearly identifiable parts are provisional or private, and the rest are covered by regular stability guarantees?" and early adopters ask themselves "Do I really want to make this a *required* dependency? Perhaps I can make it optional somehow, so folks that aren't using these features won't get the warning?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Thu Oct 12 22:32:01 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Oct 2017 02:32:01 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507858050.05.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJL82Z4XBhJt-XYcV8HPvcz3=o6e+n+fwNT4GdaT45sN9w@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I am at a loss for words.

On Oct 12, 2017 6:27 PM, "Nick Coghlan" <report at bugs.python.org> wrote:

>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> If a proposed standard library API is sufficiently stable that the folks
> proposing it are reluctant to emit a runtime warning about any remaining
> stability risks, then I think it's reasonable to expect them to propose it
> as non-provisional and accept the related backwards compatibility
> obligations.
>
> We have past examples of our being able to cope with that approach, such
> as when contextlib.nested turned out to be broken at a design level, so we
> deprecated it, removed it, and replaced it with a combination of
> contextlib.ExitStack and native support for multiple context managers in
> with statements.
>
> Framing that in different terms: with PEP 411 as currently written, the
> benefits of instability accrue to the API publisher and willing early
> adopters, while the costs appear as negative externalities affecting folks
> that would prefer not to care about the API at all until it is covered by
> the regular backwards compatibility guarantees.
>
> This RFE proposes to internalise some of those costs (in the form of a
> required runtime warning for any future provisional APIs), such that API
> publishers ask themselves "Do I *really* need this whole API to be
> provisional? Can I restructure it so only selected clearly identifiable
> parts are provisional or private, and the rest are covered by regular
> stability guarantees?" and early adopters ask themselves "Do I really want
> to make this a *required* dependency? Perhaps I can make it optional
> somehow, so folks that aren't using these features won't get the warning?"
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31742>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Thu Oct 12 22:52:05 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 13 Oct 2017 02:52:05 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507863124.99.0.213398074469.issue31732@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

No need to be brusque with me.  Vinay is the decision maker on this.

Overall, this seems rehash and second guess the discussions and decisions made 15 years ago when PEP 282 was accepted.  At that time, it was decided that five levels had advantages for learnability and usability, but that the levels should be extendable to cover more specialized uses:

    >>> import logging
    >>> SEMI_IMPORTANT = 35
    >>> logging.addLevelName(SEMI_IMPORTANT, 'SEMI_IMPORTANT')
    >>> logging.log(SEMI_IMPORTANT, 'request backlog getting high')
    SEMI_IMPORTANT:root:request backlog getting high

This effortless extendability let us avoid adding the whole zoo of names sometimes used in other projects (FATAL, TRACE, NOTICE, FINE, FINER, FINEST).  As far as I can tell, this module has a 15 year track record of success and was well thought-out from the outset.  So there is no reason to suddenly be so insistent that the module must change to accommodate your world view of how everyone else should prioritize their log entries.

As a teacher, project leader, and coach, one thing I really like about Vinay's design is that people seem to easily and naturally assign the correct rank order to the existing five levels.  Today, I asked some engineers where TRACE or NOTICE would fit in and they were unsure.  This indicates that adding new levels will impact usability and make users worse off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Fri Oct 13 00:42:07 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Oct 2017 04:42:07 +0000
Subject: [issue30632] IDLE: add unittests to test_autocomplete
In-Reply-To: <1497256222.98.0.89770351326.issue30632@psf.upfronthosting.co.za>
Message-ID: <1507869727.55.0.213398074469.issue30632@psf.upfronthosting.co.za>


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


----------
superseder:  -> IDLE: Add test_autocomplete unittest

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30632>
_______________________________________

From report at bugs.python.org  Fri Oct 13 01:00:48 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 05:00:48 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507870848.64.0.213398074469.issue31772@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Increasing the number of stat calls required for a successful import is a good reason to close the submitted PR, but I'm not sure it's a good reason to close the *issue*, as there may be other ways to solve it that don't result in an extra stat call for every successful cache hit.

Restating the problem: the pyc file format currently discards the fractional portion of the source file mtime. This means that even if the source filesystem offers a better than 1 second timestamp resolution, the bytecode cache doesn't.

So I think it's worth asking ourselves what would happen if, instead of storing the source mtime as an integer directly, we instead stored "int(mtime * N) & 0xFFFF".

The source timestamp is stored in a 32-bit field, so the current pyc format is technically already subject to a variant of the 2038 epoch problem (i.e. it will wrap in 2106 and start re-using timestamps). We just don't care, since the only impact is that there's a tiny risk that we'll fail to recompile an updated source file if it hasn't changed size and we try importing it at exactly the wrong time. That window is currently 1 second every ~136 years.

That means we have a trade-off available between the size of each individual "erroneous cache hit" window, and how often we encounter that window. Some examples:

N=2: 500 ms window every ~68 years
N=10: 100 ms window every ~13.6 years
N=100: 10 ms window every ~1.36 years
N=1000: 1 ms window every ~7 weeks (~0.136 years)

The odds of a file being in exactly 7 weeks time after it was last compiled (down to the millisecond) *and* being different without changing size are going to be lower that those of a single (or N) character change being made *right now* (e.g. fixing a typo in a variable name that transposed characters, or got a letter wrong).

A case where problems with the status quo could be most plausibly encountered is when a text editor with autosave configured is combined with a testing web service with hot reloading configured.

Don't get me wrong, I think the odds of that actually happening are already very low, and the human fix is simple (make another edit, save the source file again, and grumble about computers not seeing changes that are right in front of them).


However, encountering problems with an N=100 or N=1000 multiplier seems even more implausible to me, and in cases where it was deemed a concern, PEP 552's hash-based caching seems a solution people should be looking at anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 01:09:29 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Oct 2017 05:09:29 +0000
Subject: [issue31509] test_subprocess hangs randomly on AMD64 Windows10 3.x
In-Reply-To: <1505751373.39.0.732395658856.issue31509@psf.upfronthosting.co.za>
Message-ID: <1507871369.57.0.213398074469.issue31509@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

I also have seen test_subprocess hangs on both macOS and on Debian Linux on both 3.6 and master, as recently as 3.6.3 and 3.7.0a1 but not with current heads.  After some experimenting and bisecting, I tracked the fix down to the mock os.waitpid fixes for bpo-31178 (git11045c9d8a and gitfae0512e58). So perhaps this issue can be closed.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31509>
_______________________________________

From report at bugs.python.org  Fri Oct 13 01:12:05 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 05:12:05 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507871525.98.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, what's in PEP 558 is the least invasive implementation change I've been able to come up that fixes the reported bug, but Nathaniel's right that it would break debuggers (and probably some other things) as currently written.

So the above design comes from asking myself "How can I get the *effect* of PEP 558, while hiding what's going on internally even from trace function implementations?".

While I can't be sure until I've actually implemented it successfully (no ETA on that, unfortunately), I think blending my idea with Nathaniel's original idea will let us enjoy the benefits of both approaches, without the downsides of either of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 01:21:44 2017
From: report at bugs.python.org (pmpp)
Date: Fri, 13 Oct 2017 05:21:44 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507872104.66.0.213398074469.issue31732@psf.upfronthosting.co.za>


pmpp <pmpp.pub at gmail.com> added the comment:

Sorry, i didn't mean to be rude. Just wanted to pick your attention because i think you miss the point:  logging as is it with its levels is perfect for *log messages*.
Review the typical usage shown and you'll see that tracing level is for logging tracebacks : the debug message is separate. Traces just don't fit on standard log output, they clutter and obviously have a format of their own. 
As a user i see TRACE as context for logging.exception when it has nothing to do with errors or verbosity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Fri Oct 13 01:39:42 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 05:39:42 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507873182.39.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Keep in mind that I'm not proposing that we retroactively change our approach to managing any currently provisional APIs that were proposed and implemented under the current version of PEP 411.

Instead I'm merely suggesting that the policy for any *future* provisional APIs be amended to require a runtime feature flag and FutureWarning by default, with the possible disposition of such proposals then being:

1. Rejected (as with any proposal)
2. Accepted with the feature flag and runtime warning in place
3. The proposal is reformulated to include both non-provisional and provisional parts, with the feature flag and warning applying only to use of the latter elements
4. The proposal is reformulated to offer an entirely non-provisional public API without a feature flag or warning (perhaps with a private "_machinery" or "_internals" submodule to better enable third party tinkering and experimentation)
5. The submitter of the proposal successfully makes the case that their proposal is simultaneously stable enough that it doesn't need a feature flag or runtime warning and *un*stable enough that it shouldn't be expected to offer the standard library's usual backwards compatibility guarantees

I personally think the final option will be tricky enough to justify that most folks won't even bother trying, and will instead opt for one side or the other (i.e. the feature-flag-and-warning, or a non-provisional API)

However, it's an option I'd consider reasonable to retain in recognition of the fact that it's been used without problems in the past (e.g. it's plausible that pathlib could credibly have made that case, since the provisional status wasn't due to potential API stability within pathlib itself, it was due to doubts about how well it would be able to integrate with other parts of the standard library. It went unprovisional once the introduction of the filesystem path protocol allowed those integration concerns to be fully resolved).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Fri Oct 13 02:19:53 2017
From: report at bugs.python.org (Devin Bayer)
Date: Fri, 13 Oct 2017 06:19:53 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507875593.54.0.213398074469.issue31772@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

Thanks for the support Nick. I think your proposed idea would still result in rare but confusing behavior, which is the type of surprise Python should avoid.

The hash-based pyc files doesn't seem like a solution to me, because it won't be enabled by default. And I think it's obvious the performance loss of doing so is unacceptable.

If changing the bytecode format is unacceptable, though it seems like the cleanest answer, the import machinery could just avoid caching bytecode when the int(mtime) of the source file is potentially in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 02:47:07 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 06:47:07 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507877227.8.0.213398074469.issue31772@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The problem with changing the bytecode format is that code other than the import machinery reads the bytecode headers, so when we change the format, we need to consider the impact on that code. (Even my multiplication proposal above suffers from that problem)

A freshness check that would avoid the extra stat call, while still making the import system skeptical of the validity of the bytecode cache for just-edited sources would be to also check the source mtime against the *current* time: if they're the same within the resolution of the bytecode format (i.e. 1 second), then compile the code again even if the bytecode headers claims it's already up to date.

That way hot reloaders would be sure to pick up multiple edits to the source file properly, and would reliably be left with the final version loaded, rather than the first version from the final second of edits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 02:51:57 2017
From: report at bugs.python.org (Devin Bayer)
Date: Fri, 13 Oct 2017 06:51:57 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507877517.12.0.213398074469.issue31772@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

That wouldn't always work either. If the source file is imported, then edited, then not reimported until the next second (or far in the future) the stale bytecode would still be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:02:27 2017
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 13 Oct 2017 07:02:27 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507878147.3.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset b22273ec5d1992b0cbe078b887427ae9977dfb78 by INADA Naoki in branch 'master':
bpo-31672: Fix string.Template accidentally matched non-ASCII identifiers (GH-3872)
https://github.com/python/cpython/commit/b22273ec5d1992b0cbe078b887427ae9977dfb78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:11:43 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 07:11:43 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507878703.95.0.213398074469.issue31772@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If there's no hot reloader forcing a reimport for every saved edit, it's sufficiently unlikely to encounter this problem in the first place that I'm not worried about that scenario. (The time required for a human to context switch from code editing to code execution and back sees to that)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:31:27 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 13 Oct 2017 07:31:27 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507879887.92.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

I guess I should say that I'm still confused about why we're coming up with such elaborate schemes here, instead of declaring that f_locals and locals() shall return a dict proxy so that from the user's point of view, they Always Just Work The Way Everyone Expects.

The arguments against that proposal I'm aware of are:

1) Implementing a full dict-like mapping object in C is tiresome. But your proposal above also requires doing this, so presumably that's not an issue.

2) We want to keep the current super-complicated and confusing locals() semantics, because we like making life difficult for alternative implementations (PyPy at least exactly copies all the weird details of how CPython's locals() works, which is why it inherited this bug), and by making the language more confusing we can encourage the use of linters and boost Python's Stackoverflow stats. ...I guess my bias against this argument is showing :-). But seriously, if we want to discourage writing to locals() then the way to do that is to formally deprecate it, not go out of our way to make it silently unreliable.

3) According to the language spec, all Python implementations have to support locals(), but only some of them have to support frame introspection, f_locals, debugging, and mutation of locals. But... I think this is a place where the language spec is out of touch with reality. I did a quick survey and AFAICT in practice, Python implementations either support *both* locals() and f_locals (CPython, PyPy, Jython, IronPython), or else they support *neither* locals() nor f_locals (MicroPython -- in fact MicroPython defines locals() to unconditionally return an empty dict). We could certainly document that supporting writes through locals() is a quality-of-implementation thing CPython provides, similar to the prompt destruction guarantees provided by refcounting. But I don't think implementing this is much of a burden -- if you have enough introspection metadata to get the list of locals and figure out where their values are stored in memory (which is the absolute minimum to implement locals()), then you probably also have enough metadata to write back to those same locations. Plus debugger support is obviously a priority for any serious full-fledged implementation.

So the original write-through proxy idea still seems like the best solution to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:33:11 2017
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 13 Oct 2017 07:33:11 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507879991.98.0.213398074469.issue31672@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +3958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:33:55 2017
From: report at bugs.python.org (Devin Bayer)
Date: Fri, 13 Oct 2017 07:33:55 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507880035.69.0.213398074469.issue31772@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

You can't demand a hot loader to react instantly and there are other use cases, like generating modules programatically.

What is your objection to my proposed solution, which behaves correctly in all cases?

If you are not importing modules immediately after writing them, there is no harm in skipping the cache if the file mtime differs from the current time.

If you are importing modules immediately, then you want to bypass the cache in that case, since it can't be relied upon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:39:39 2017
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 13 Oct 2017 07:39:39 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507880379.45.0.213398074469.issue30744@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

FWIW, a Psyco-level JIT compiler can support reads from locals() or f_locals, but writes are harder.  The need to support writes would likely become another hard step on the way towards adding some simple JIT support to CPython in the future, should you decide you ever want to go that way.  (It is not a problem for PyPy but PyPy is not a simple JIT.)  Well, I guess CPython is not ever going down that path anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:41:34 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 Oct 2017 07:41:34 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507880494.38.0.213398074469.issue31732@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

As Raymond has said: though it might appear reasonable to add a TRACE level from the numerous examples that Victor has given, in practice it is hard enough to know when a particular level should be applied. Victor says "we need to a 6th level since DEBUG might be too verbose" - but as the PR is currently constituted, enabling the TRACE level would output DEBUG messages too, and so be even more verbose than just DEBUG! In this case I feel that, when considering the number of levels, "less is more".

For specific applications different levels might be desirable, and the logging system makes this possible, though not at the level of convenience of having a trace() method on loggers. However, it's easy enough to provide your own subclass with that method, if you really need it that badly. Of course you can currently also do logger.log(TRACE, ...) without the need for any subclass or need to "patch the stdlib" (as per Victor's comment).

This is one of those areas where tastes differ - and it is IMO really just a matter of taste. The five levels we have presently are based on what was considered best practice when the logging module was added to Python, and it specifically eschewed adopting prior art where more levels were available (e.g. syslog). The documentation gives a clear rationale for when to use what level:

https://docs.python.org/2/howto/logging.html#when-to-use-logging

and this seems of reasonably universal applicability across projects.

Given that individual projects *can* provide additional levels according to their need, I feel that there is no need for a TRACE level in the stdlib; as Raymond has pointed out in msg304304, the current levels are easy to understand when to apply, and finer levels invariably lead to different opinions on when to use them, due to essentially being matters of taste.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:46:41 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 13 Oct 2017 07:46:41 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507880801.39.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

@arigo: But CPython is already committed to supporting writes to locals() at any moment, because at any moment you can set a trace function and in every proposal trace functions can reliably write to locals. So I don't think this is a serious obstacle for addng a JIT to CPython -- or at least, it doesn't add any new obstacles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:49:55 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 07:49:55 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507880995.08.0.213398074469.issue31772@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I wasn't clear on what you meant by "potentially in the future".

Now that I realise you meant "Defer refreshing the bytecode cache to the next import attempt if `int(source_mtime) == int(time.time())`, but still bypass it for the current import", then yes, I agree that would reliably resolve the problem, since all imports during the same second as the edit would bypass the cache without updating it, and the first subsequent import would refresh it a timestamp that's guaranteed to be later than the source_mtime (not just equal).

Brett, what do you think? Such an adjustment to the caching logic should have next to no impact in the typical case where `int(source_mtime) < int(time.time())`, while still making it even less likely that hot reloaders will accidentally cache stale bytecode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:53:46 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 Oct 2017 07:53:46 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507881226.97.0.213398074469.issue30767@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Matthew Patton: you don't appear to have read the documentation correctly. The formatException() method's exc_info positional parameter is expected to be a normal exception tuple, not just any truthy value. This is clearly stated in the documentation for the method.

That is different to the logger.debug() etc. methods, where a truthy value can be provided for the exc_info keyword parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Fri Oct 13 03:59:13 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 13 Oct 2017 07:59:13 +0000
Subject: [issue31758] various refleaks in _elementtree
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1507881553.07.0.213398074469.issue31758@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Shame on me. I only now found out that Serhiy already mentioned most of the refleaks
in https://bugs.python.org/issue31455#msg302103.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Fri Oct 13 04:05:00 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 08:05:00 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507881900.25.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We're OK with the idea that installing a trace function might automatically turn off various compiler and interpreter managed optimisations (it's similar to how requesting or implying reliance on full frame support in other implementations can disable various optimisations). For trace hooks like coverage tools and debuggers, that's often downright desirable, since it makes the runtime behaviour correlate more directly with the source code.

What we're aiming to avoid is requiring that implementations make the assertion in "a = 1; locals('a') = 2; assert a == 2" pass at function scope, and if anything, we'd prefer to make it a requirement for that assertion to *fail*.

Requiring locals to actually *be* a write-through proxy (for all locals, not just cell references) would revert Python's semantics to the state they were in before the "fast locals" concept was first introduced, and we have no intention of going back there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 04:05:04 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 13 Oct 2017 08:05:04 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1507881904.8.0.213398074469.issue31455@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

Serhiy, in addition to the problems you mentioned with not calling __init__(), it seems
that calling every method of an uninitialized XMLParser object would crash.

If you don't mind, i would be happy to open an issue to fix these crashes.

----------
nosy: +Oren Milman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Fri Oct 13 04:16:50 2017
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 13 Oct 2017 08:16:50 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507882610.01.0.213398074469.issue30744@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Thanks Nick for the clarification.  Yes, that's what I meant: supporting such code in simple JITs is a nightmare.  Perhaps more importantly, I am sure that if Python starts supporting random mutation of locals outside tracing hooks, then it would open the door to various hacks that are best not done at all, from a code quality point of view.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 04:33:08 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 08:33:08 +0000
Subject: [issue31761] regrtest: faulthandler.enable() fails with
 io.UnsupportedOperation: fileno when run from IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1507883588.61.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

After starting Python from a command line instead of an icon, importing/running autotest results in the same three failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Fri Oct 13 05:30:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 09:30:02 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1507887002.71.0.213398074469.issue31773@psf.upfronthosting.co.za>


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


----------
pull_requests: +3959

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Fri Oct 13 05:52:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 09:52:23 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1507888343.34.0.213398074469.issue31773@psf.upfronthosting.co.za>


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

I reopen the issue since I found a solution to only use integer in pytime.c for QueryPerformanceCounter() / QueryPerformanceFrequency() *and* prevent integer overflow.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Fri Oct 13 06:54:20 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 13 Oct 2017 10:54:20 +0000
Subject: [issue31779] assertion failures and a crash when using an
 uninitialized struct.Struct object
Message-ID: <1507892060.42.0.213398074469.issue31779@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code causes an assertion failure:
    import _struct
    struct_obj = _struct.Struct.__new__(_struct.Struct)
    struct_obj.iter_unpack(b'foo')

This is because Struct_iter_unpack() (in Modules/_struct.c) assumes that
Struct.__init__() was called, and so it does `assert(self->s_codes != NULL);`.

The same happens in (almost) every method of Struct, and in s_get_format(), so
in all them, too, we would get an assertion failure in case of an uninitialized
Struct object.
The exception is __sizeof__(), which doesn't have an `assert`, and simply
crashes while trying to iterate over `self->s_codes`.


I would open a PR to fix this soon.

----------
components: Extension Modules
messages: 304328
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: assertion failures and a crash when using an uninitialized struct.Struct object
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31779>
_______________________________________

From report at bugs.python.org  Fri Oct 13 07:32:35 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Oct 2017 11:32:35 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507894355.66.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll also note there's a simpler reason the namespace object exposed at the function level can't just be a write-through proxy for the underlying frame: references to frame.f_locals may outlive the frame backing it, at which point we really do want it to be a plain dictionary with no special behaviour, just as it is for regular execution frames. 

(Think "return locals()" as the last line in a helper function, as well as variants like "data = locals(); data.pop('some_key'); return data")

That means that no matter what, we need to snapshot the frame locals the when frame.f_locals is requested. The question then becomes:

- when we do we update the contents of cell references? (this is what's buggy right now when a trace function is installed)
- when do we update ordinary local variables? (this isn't broken, so we want to avoid changing it)

Providing write-through support *just* for cells should thus make it possible to fix the buggy interaction between cells and trace function, while minimising the risk of any unintended consequences affecting regular function locals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 07:36:55 2017
From: report at bugs.python.org (FHTMitchell)
Date: Fri, 13 Oct 2017 11:36:55 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
Message-ID: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>


New submission from FHTMitchell <fergus.htm at gmail.com>:

Minor issue. Using the ',b', ',o' or ',x' raises the error

ValueError("Cannot specify ',' or '_' with 'x'.",)

(or equivalently for 'b' and 'o'). However, it is possible to use the format specs '_b', '_o' and '_x' in Python 3.6 due to PEP 515. 

The following test demonstrates this:

>>> i = 10000
>>> for base in 'box':
...     for sep in ',_':
...         try:
...             print(f'{i:{sep}{base}}')
...         except ValueError as err:
...             print(repr(err))

ValueError("Cannot specify ',' or '_' with 'b'.",)
1_1000_0110_1010_0000
ValueError("Cannot specify ',' or '_' with 'o'.",)
30_3240
ValueError("Cannot specify ',' or '_' with 'x'.",)
1_86a0

----------
messages: 304330
nosy: FHTMitchell
priority: normal
severity: normal
status: open
title: Using format spec ',x' displays incorrect error message
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Fri Oct 13 08:16:36 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Oct 2017 12:16:36 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507896996.81.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 7f580970836b0f6bc9c5db868d95bea81a3e1558 by Berker Peksag in branch 'master':
bpo-28647: Update -u documentation after bpo-30404 (GH-3961)
https://github.com/python/cpython/commit/7f580970836b0f6bc9c5db868d95bea81a3e1558


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Fri Oct 13 08:16:37 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Oct 2017 12:16:37 +0000
Subject: [issue30404] Make stdout and stderr truly unbuffered when using -u
 option
In-Reply-To: <1495209125.34.0.468493818937.issue30404@psf.upfronthosting.co.za>
Message-ID: <1507896997.04.0.912454111764.issue30404@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 7f580970836b0f6bc9c5db868d95bea81a3e1558 by Berker Peksag in branch 'master':
bpo-28647: Update -u documentation after bpo-30404 (GH-3961)
https://github.com/python/cpython/commit/7f580970836b0f6bc9c5db868d95bea81a3e1558


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30404>
_______________________________________

From report at bugs.python.org  Fri Oct 13 08:17:18 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Oct 2017 12:17:18 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507897038.14.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for reviews, Serhiy and Victor.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Fri Oct 13 09:01:33 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 13:01:33 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507899693.26.0.213398074469.issue28647@psf.upfronthosting.co.za>


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

Thanks Berker for this nice documentation enhancement! It was required.

Do we need to update Python 3.6 documentation using the commit 5f908005ce16b06d5af7b413264009c4b062f33c, or are we good? (sorry, I didn't check)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Fri Oct 13 09:07:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 13:07:27 +0000
Subject: [issue22674] RFE: Add signal.strsignal(): string describing a signal
In-Reply-To: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>
Message-ID: <1507900047.51.0.213398074469.issue22674@psf.upfronthosting.co.za>


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

> 3. For the unknown signal, what is the description should be? "Unknown signal" like c function returns or None?

Hum, Linux returns "Unknown signal 12345". I propose to use this behaviour on all platforms (which provide strsignal()).

----------
title: strsignal() missing from signal module -> RFE: Add signal.strsignal(): string describing a signal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22674>
_______________________________________

From report at bugs.python.org  Fri Oct 13 09:23:37 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Oct 2017 13:23:37 +0000
Subject: [issue28647] python --help: -u is misdocumented as binary mode
In-Reply-To: <1478687165.61.0.754522524524.issue28647@psf.upfronthosting.co.za>
Message-ID: <1507901017.1.0.213398074469.issue28647@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Modules/main.c and Python.man is same in 3.6 branch. We could backport the change in Doc/library/sys.rst from 7f580970836b0f6bc9c5db868d95bea81a3e1558 but I didn't do it yet since it needs be manually backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28647>
_______________________________________

From report at bugs.python.org  Fri Oct 13 09:29:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 13:29:51 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507901391.24.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

Vinay:
> I feel that there is no need for a TRACE level in the stdlib

Ok, that's fine.

I just pushed the idea of someone on IRC. Since I had the same idea once, I tried, but I lost :-) I can easily survive without TRACE in the stdlib ;-)


Vinay:
> Victor says "we need to a 6th level since DEBUG might be too verbose" - but as the PR is currently constituted, enabling the TRACE level would output DEBUG messages too, and so be even more verbose than just DEBUG! In this case I feel that, when considering the number of levels, "less is more".

Oh, I'm not sure that I explained my point correctly, since someone else on IRC told me that he misunderstood.

My point is that logs have different consumers who have different expectations and usages of the logs.

In my case, the customer may want to go to up to the DEBUG level "by default" to collect more data on failures. Enabling TRACE would produce too many logs and should be restricted to the most tricky bugs where you cannot guess the bug only with the DEBUG level.

I tried to explain that if you are putting all debug traces at the DEBUG level, you may produce 10 MB of log per minute (arbitrary number for my explanation). But producing 10 MB per machine in a large datacenter made of thousands of servers can lead to practical storage issues: too many logs would fill the log partition too quickly, especially when logs are centralized.

The idea is to reduce debug traces to 10% at the DEBUG level, and put the remaings traces at the TRACE level. For example, you can imagine to log an exception message at DEBUG, but log the traceback at TRACE level. The traceback is likely to produce 10x more logs.

The TRACE level is only enabled on-demand for a short period of time on a few selected servers.

Technically, you can already do that INFO and DEBUG levels. But in OpenStack, these levels are already "busy" with enough messages and we needed a 6th level :-)

(I don't want to reopen the discssion, just to make sure that I was correctly understood ;-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Fri Oct 13 09:51:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Oct 2017 13:51:06 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1507902666.52.0.213398074469.issue31455@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It would be nice. But I see you already have opened issue31758 for reference leaks. I think that other problems can be solved in the same issue.

Do you mind to backport your patch to 2.7 Stefan? If this makes sense. Otherwise I'll just close this issue. Live exceptions don't cause crash in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Fri Oct 13 09:55:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 13:55:14 +0000
Subject: [issue31509] test_subprocess hangs randomly on AMD64 Windows10 3.x
In-Reply-To: <1505751373.39.0.732395658856.issue31509@psf.upfronthosting.co.za>
Message-ID: <1507902914.83.0.213398074469.issue31509@psf.upfronthosting.co.za>


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

Ned: "I also have seen test_subprocess hangs on both macOS and on Debian Linux on both 3.6 and master, as recently as 3.6.3 and 3.7.0a1 but not with current heads.  After some experimenting and bisecting, I tracked the fix down to the mock os.waitpid fixes for bpo-31178 (git11045c9d8a and gitfae0512e58). So perhaps this issue can be closed."

Oh, that's a very good news. Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31509>
_______________________________________

From report at bugs.python.org  Fri Oct 13 10:05:52 2017
From: report at bugs.python.org (Matthew Patton)
Date: Fri, 13 Oct 2017 14:05:52 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507903552.58.0.213398074469.issue30767@psf.upfronthosting.co.za>


Matthew Patton <pattonme at yahoo.com> added the comment:

I've triggered it which is why I looked for the problem and offered the defensive patch. As API writers you can NEVER assume your parameters are what you think they should be and just blindly proceed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Fri Oct 13 10:14:21 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 13 Oct 2017 14:14:21 +0000
Subject: [issue31779] assertion failures and a crash when using an
 uninitialized struct.Struct object
In-Reply-To: <1507892060.42.0.213398074469.issue31779@psf.upfronthosting.co.za>
Message-ID: <1507904061.5.0.213398074469.issue31779@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3960
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31779>
_______________________________________

From report at bugs.python.org  Fri Oct 13 10:20:06 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 13 Oct 2017 14:20:06 +0000
Subject: [issue30767] logging must check exc_info correctly
In-Reply-To: <1498483385.09.0.415131659339.issue30767@psf.upfronthosting.co.za>
Message-ID: <1507904406.17.0.213398074469.issue30767@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I've triggered it which is why I looked for the problem and offered the defensive patch.

That's why I asked for a small example which used logging as documented and demonstrated a problem. You haven't done that.

> As API writers you can NEVER assume your parameters are what you think they should be and just blindly proceed.

I think you'll find that in Python usage in general and the Python stdlib in particular, exhaustive checking of input parameters is not the norm. I'm not saying that no error checking is ever done nor that it should never be done, but your "NEVER" doesn't seem to hold up, as the stdlib contains many counterexamples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30767>
_______________________________________

From report at bugs.python.org  Fri Oct 13 11:05:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 15:05:55 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1507907155.92.0.213398074469.issue30156@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3961

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Fri Oct 13 11:08:41 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 15:08:41 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1507907321.61.0.213398074469.issue30156@psf.upfronthosting.co.za>


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

> Removing this micro-optimization makes attribute access in namedtuple more than 1.5 times slower:
> Mean +- std dev: [python.default] 126 ns +- 4 ns -> [python] 200 ns +- 7 ns: 1.58x slower (+58%)

I wrote the PR 3985, it's only 20 ns slower (1.3x slower):

[ref] 80.4 ns +- 3.3 ns -> [fastcall] 103 ns +- 5 ns: 1.28x slower (+28%)

Maybe Python was optimized further in the meanwhile, or the slowdown is higher on your computer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Fri Oct 13 11:14:13 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 15:14:13 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1507907653.3.0.213398074469.issue30156@psf.upfronthosting.co.za>


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

Note: if you care of namedtuple performance, Raymond Hettinger wrote that he would be interested to reuse the C structseq sequence. I measured that getting an attribute by name is faster in structseq than with the current property cached tuple hack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Fri Oct 13 11:59:43 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Oct 2017 15:59:43 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1507910383.11.0.213398074469.issue31780@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Fri Oct 13 12:16:54 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Fri, 13 Oct 2017 16:16:54 +0000
Subject: [issue28507] Regenerate ./configure on the default branch
In-Reply-To: <1477155371.02.0.736357632927.issue28507@psf.upfronthosting.co.za>
Message-ID: <1507911414.8.0.213398074469.issue28507@psf.upfronthosting.co.za>


????? ???????? <dilyan.palauzov at aegee.org> added the comment:

For the record, on master runstatedir was added on 7th September 2017, removed on 5th September, added on 29 June, removed on 9th June, added on 14th April, removed on 6th December 2016 and 10th October in two branches, added on 13th September...

The history would be easier to understand and follow, if one clarifies whether runstatedir belongs to configure and then everybody sticks to the same rule.

Autoconf 2.69 does not insert runstatedir, autoconf.git since 12 September 2013 does insert runstatedir.

----------
nosy: +dilyan.palauzov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28507>
_______________________________________

From report at bugs.python.org  Fri Oct 13 12:31:24 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Oct 2017 16:31:24 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507912284.88.0.213398074469.issue30744@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hm.... I may just be completely off here, but I thought that compilers could be allowed to recognize the use of locals() in a particular function and then disable JIT optimizations for that function. (In fact I thought we already had a rule like this but I can't find any language about it, but maybe I'm mistaken and we only have such an exception for sys._getframe() -- though it's not mentioned in the docs for that either.)

I do like Nathaniel's idea of making locals() a write-through proxy (and let f_locals the same thing). If this keeps the frame alive, well too bad -- there are lots of other things that do this too, e.g. tracebacks.

Or what about a read-only proxy or a plain snapshot? The docs already say that it *shouldn't* be written and *may* not write through -- are we concerned that a lot of people depend on the actual runtime behavior rather than the documented behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 12:56:47 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 13 Oct 2017 16:56:47 +0000
Subject: [issue31781] crashes when calling methods of an uninitialized
 zipimport.zipimporter object
Message-ID: <1507913807.6.0.213398074469.issue31781@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

The following code crashes:
import zipimport
zi = zipimport.zipimporter.__new__(zipimport.zipimporter)
zi.find_module('foo')

This is because get_module_info() (in Modules/zipimport.c) assumes that the
zipimporter object is initialized, so it assumes that `self->prefix` is not
NULL, and passes it to make_filename(), which crashes.

get_module_code() makes the same assumption, and zipimport_zipimporter_get_data_impl()
assumes that `self->archive` is not NULL, and passes it to PyUnicode_GET_LENGTH(),
which crashes.
Thus, every method of an uninitialized zipimporter object might crash.


I would open a PR to fix this soon.

----------
components: Extension Modules
messages: 304346
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: crashes when calling methods of an uninitialized zipimport.zipimporter object
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31781>
_______________________________________

From report at bugs.python.org  Fri Oct 13 13:03:53 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Oct 2017 17:03:53 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507914233.94.0.213398074469.issue31742@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think this ought to be a new PEP which supersedes PEP 411. I think it should simply *offer* the option of using a feature flag rather than prescribing it. It could also explain that feature flags could cover an entire module or only the unstable parts. I would be happy to accept something like that.

I am still unclear as to how you are proposing to implement the "feature flag". Making this an attribute of `__main__` doesn't feel right (I've seen programs with different main entry point). However I do think it could be global state, similar to what `warnings` does (maybe it should just be a warning).

I don't like the parallel with `__future__` imports because those are for *stable* APIs that use backwards incompatible syntax (typically a new keyword).

Thinking back on my experiences with asyncio and typing, I have a feeling that the provisional status was *mostly* used to introduce *new* APIs at bugfix releases. We were in general pretty careful with changes to the documented APIs, with some exceptions for where the design was broken, and we sometimes pushed backwards incompatibilities to feature releases (which get more vetting by users than bugfix releases). But in both cases the API surface was sufficiently large that we simply didn't know in which areas details would have to change in the future, and we didn't want to be stuck with backwards compatibility hacks long-term. (The worst thing is when the perfect name for an API is found to require an incompatible signature change -- if you solve it by using a different the API will forever look ugly or confusing or weird.)

I know there have been times for both asyncio and typing where we wished they weren't in the stdlib at all -- mostly because we had users stuck with a CPython version (e.g. 3.5.1) that was missing an important addition to the API. But all in all I think that for both libraries the advantages have well outweighed the disadvantages. And a required warning on import would have really bothered me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Fri Oct 13 13:09:12 2017
From: report at bugs.python.org (Aaron Gallagher)
Date: Fri, 13 Oct 2017 17:09:12 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507914552.36.0.213398074469.issue31742@psf.upfronthosting.co.za>


Aaron Gallagher <_ at habnab.it> added the comment:

>Storing the marker attribute in __main__ [...]

Can I request please not using __main__ for this? setuptools console_scripts are very common, which is a case where __main__ will be a generated (i.e. not user-controllable) file. Making application code import __main__ to set the flag would be brittle.

----------
nosy: +habnabit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Fri Oct 13 13:11:58 2017
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Oct 2017 17:11:58 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507914718.74.0.213398074469.issue31772@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

To make the proposal concrete, would you then change https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap_external.py#L785 to include a `source_mtime != int(time.time())` guard? I think as long as that's the last check in the guard since that has they highest performance cost it should be okay (I don't think any platform makes calling the clock an expensive operation).

And nothing personal about pro-actively closing this, Devin, but with over 6000 issues in this issue tracker alone it's easier to ask forgiveness than permission when it comes to issues that at the outset don't look like a good idea. Otherwise I would have to track this issue personally in case you never responded again (which does happen), and that just becomes a maintenance burden on me when I have 3 other Python-related projects that I'm also actively working on issues with (ignoring any issues that I get involved with on this tracker).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Fri Oct 13 13:50:31 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 17:50:31 +0000
Subject: [issue31727] FTP_TLS errors when use certain subcommands
In-Reply-To: <1507482521.5.0.213398074469.issue31727@psf.upfronthosting.co.za>
Message-ID: <1507917031.53.0.213398074469.issue31727@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
title: FTP_TLS errors when -> FTP_TLS errors when use certain subcommands
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31727>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:23:42 2017
From: report at bugs.python.org (Will Starms)
Date: Fri, 13 Oct 2017 19:23:42 +0000
Subject: [issue31782] Add a timeout to multiprocessing's Pool.join
Message-ID: <1507922622.85.0.213398074469.issue31782@psf.upfronthosting.co.za>


New submission from Will Starms <vilhelmen at gmail.com>:

Pool's join function currently (3.6.3) lacks a timeout, which can cause the managing thread to sleep indefinitely when a pool worker hangs or starts misbehaving. Adding a timeout allows the owning thread to attempt a join and, after the timeout, return to other tasks, such as monitoring worker health.

In my specific situation, I have a Pool running a task on a large set of files. If any single task fails, the whole operation is ruined and the pool should be terminated. A task can communicate with the main thread through error_callback, but if the thread has already called join, it can't check until join returns, after the Pool has finished all processing.

Attached is an incredibly simple patch to the current (3.6) cpython implementation that emulates threading.thread.join's behavior.

----------
components: Library (Lib)
files: cpython_timeout.patch
keywords: patch
messages: 304350
nosy: Will Starms
priority: normal
severity: normal
status: open
title: Add a timeout to multiprocessing's Pool.join
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file47219/cpython_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31782>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:27:54 2017
From: report at bugs.python.org (Oren Milman)
Date: Fri, 13 Oct 2017 19:27:54 +0000
Subject: [issue31781] crashes when calling methods of an uninitialized
 zipimport.zipimporter object
In-Reply-To: <1507913807.6.0.213398074469.issue31781@psf.upfronthosting.co.za>
Message-ID: <1507922874.04.0.213398074469.issue31781@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3962
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31781>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:32:13 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 19:32:13 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1507923133.67.0.213398074469.issue31752@psf.upfronthosting.co.za>


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

On Win10, installed 3.5.4, 3.6.3, 3.7.1a1 all raise SystemError.
3.6 and 3.7 repository debug builds raise AssertionError and Windows crash box.  After the patch, a silent crash.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:39:14 2017
From: report at bugs.python.org (Will Starms)
Date: Fri, 13 Oct 2017 19:39:14 +0000
Subject: [issue31782] Add a timeout to multiprocessing's Pool.join
In-Reply-To: <1507922622.85.0.213398074469.issue31782@psf.upfronthosting.co.za>
Message-ID: <1507923554.24.0.213398074469.issue31782@psf.upfronthosting.co.za>


Will Starms <vilhelmen at gmail.com> added the comment:

A timeout alternative that raises TimeoutError

----------
Added file: https://bugs.python.org/file47220/cpython_raise_timeout.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31782>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:58:38 2017
From: report at bugs.python.org (Ryan C. Decker)
Date: Fri, 13 Oct 2017 19:58:38 +0000
Subject: [issue31705] test_sha256 from test_socket fails on ppc64le arch
In-Reply-To: <1507233504.45.0.213398074469.issue31705@psf.upfronthosting.co.za>
Message-ID: <1507924718.55.0.213398074469.issue31705@psf.upfronthosting.co.za>


Ryan C. Decker <rdecker at siena.edu> added the comment:

I seem to be having this issue on CentOS 7.4 but running on x86_64 instead of ppc64le. I have attached an strace using version 4.17 (the lastest version from scl) created as follows:

strace -s 128 -e trace=%network -o trace ./python -m test -v test_socket -m test_sha256


== CPython 3.6.3 (default, Oct 13 2017, 11:16:36) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
== Linux-3.10.0-693.2.2.el7.x86_64-x86_64-with-centos-7.4.1708-Core little-endian
== cwd: /home/ryan/Downloads/Python-3.6.3/build/test_python_4140
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.13 [1/1] test_socket
test_sha256 (test.test_socket.LinuxKernelCryptoAPI) ... ERROR

======================================================================
ERROR: test_sha256 (test.test_socket.LinuxKernelCryptoAPI)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ryan/Downloads/Python-3.6.3/Lib/test/test_socket.py", line 5424, in test_sha256
    op.sendall(b"abc")
OSError: [Errno 126] Required key not available

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (errors=1)
test test_socket failed
test_socket failed

1 test failed:
    test_socket

Total duration: 39 ms
Tests result: FAILURE

----------
nosy: +Ryan C. Decker
Added file: https://bugs.python.org/file47221/trace_x86_64

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31705>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:59:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 19:59:15 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507924755.64.0.213398074469.issue25588@psf.upfronthosting.co.za>


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


New changeset ccef823939d4ef602f2d8d13d0bfec29eda597a5 by Victor Stinner in branch 'master':
bpo-25588: Fix regrtest when run inside IDLE (#3962)
https://github.com/python/cpython/commit/ccef823939d4ef602f2d8d13d0bfec29eda597a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Fri Oct 13 15:59:25 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Oct 2017 19:59:25 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507924765.88.0.213398074469.issue25588@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3963

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:05:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 20:05:34 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507925134.8.0.213398074469.issue30744@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:23:19 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Fri, 13 Oct 2017 20:23:19 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1507926199.83.0.213398074469.issue31754@psf.upfronthosting.co.za>


Aniket Vyas <vyas45 at gmail.com> added the comment:

Hello !  I am new to the community and would love to start my contribution here. Can I take up this bug ? 

In order to do so I am going through the following links: 

https://docs.python.org/devguide/docquality.html
https://docs.python.org/devguide/pullrequest.html

Is the list exhaustive for this particular issue ? 

Thanks !

----------
nosy: +Aniket Vyas

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:33:07 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 20:33:07 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1507926787.56.0.213398074469.issue31753@psf.upfronthosting.co.za>


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

On win10, installed 3.7.0a1, speedup is 7-8% (It is 'only' 5% on repository debug build that takes 5-6 times longer.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:42:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 20:42:29 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1507927349.26.0.213398074469.issue25588@psf.upfronthosting.co.za>


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


New changeset 6234e9068332f61f935cf13fa5b1a924a99c28b2 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-25588: Fix regrtest when run inside IDLE (GH-3962) (#3987)
https://github.com/python/cpython/commit/6234e9068332f61f935cf13fa5b1a924a99c28b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:47:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 20:47:51 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507927671.28.0.213398074469.issue31676@psf.upfronthosting.co.za>


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


New changeset a505ecdc5013cd8f930aacc1ec4fb2afa62d3853 by Victor Stinner in branch 'master':
bpo-31676: Fix test_imp.test_load_source() side effect (#3871)
https://github.com/python/cpython/commit/a505ecdc5013cd8f930aacc1ec4fb2afa62d3853


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:49:11 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Oct 2017 20:49:11 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507927751.58.0.213398074469.issue31676@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3964

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:49:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 20:49:45 +0000
Subject: [issue30807] setitimer() can disable timer by mistake
In-Reply-To: <1498765750.02.0.334201584192.issue30807@psf.upfronthosting.co.za>
Message-ID: <1507927785.57.0.213398074469.issue30807@psf.upfronthosting.co.za>


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


New changeset ef611c96eab0ab667ebb43fdf429b319f6d99890 by Victor Stinner in branch 'master':
bpo-30807: signal.setitimer() now uses _PyTime API (GH-3865)
https://github.com/python/cpython/commit/ef611c96eab0ab667ebb43fdf429b319f6d99890


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30807>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:52:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 20:52:10 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1507927930.78.0.213398074469.issue31676@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Fri Oct 13 16:54:50 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 13 Oct 2017 20:54:50 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1507928090.39.0.213398074469.issue31754@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Welcome Aniket. Yes those two links are good starting points.
Please propose a PR with the fix.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:15:40 2017
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 13 Oct 2017 21:15:40 +0000
Subject: [issue31759] re wont recover nor fail on runaway regular expression
In-Reply-To: <1507733773.23.0.213398074469.issue31759@psf.upfronthosting.co.za>
Message-ID: <1507929340.95.0.213398074469.issue31759@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

@Tim: the regex module includes some extra checks to reduce the chance of excessive backtracking. In the case of the OP's example, they seem to be working. However, it's difficult to know when adding such checks will help, and your example is one case where they are being done but aren't helping, with the result that it's slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31759>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:16:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 21:16:29 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1507929389.88.0.213398074469.issue14465@psf.upfronthosting.co.za>


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

For the record, at 2015-04-02, the bpo-23847 has been marked as a duplicate of this issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:24:28 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 21:24:28 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507929868.51.0.213398074469.issue31757@psf.upfronthosting.co.za>


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

I agree that we should be consistent -- with the current standard definition -- with the changes suggested above.  Heinrich, can you, and do you want to, submit a patch?  If so, please also sign the contributor agreement.  See https://www.python.org/psf/contrib/

The Fibonacci numbers start with 1 if there is no F(0), as in Fibonacci's rabbit model.  Before 0 was accepted as a number, the series had to start with F(1) = F(2) = 1.  See https://en.wikipedia.org/wiki/Fibonacci_number

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:27:16 2017
From: report at bugs.python.org (Steven Barker)
Date: Fri, 13 Oct 2017 21:27:16 +0000
Subject: [issue31783] Race condition in ThreadPoolExecutor when scheduling new
 jobs while the interpreter shuts down
Message-ID: <1507930035.71.0.213398074469.issue31783@psf.upfronthosting.co.za>


New submission from Steven Barker <blckknght at gmail.com>:

While investigating a Stack Overflow question (here: https://stackoverflow.com/q/46529767/1405065), I found that there may be a race condition in the cleanup code for concurrent.futures.ThreadPoolIterator. The behavior in normal situations is fairly benign (the executor may run a few more jobs than you'd expect, but exits cleanly), but in rare situations it might lose track of a running thread and allow the interpreter to shut down while the thread is still trying to do work.

Here's some example that concisely demonstrates the situation where the issue can come up (it doesn't actually cause the race to go the wrong way on my system, but sets up the possibility for it to occur):


from threading import current_thread
from concurrent.futures import ThreadPoolExecutor
from time import sleep

pool = ThreadPoolExecutor(4)

def f(_):
    print(current_thread().name)
    future = pool.submit(sleep, 0.1)
    future.add_done_callback(f)
    
f(None)


The callback from completion of one job schedules another job, indefinitely.

When run in an interactive session, this code will print thread names forever. You should get "MainThread" once, followed by a bunch of "ThreadPoolExecutor-X_Y" names (often the same name will be repeated most of the time, due to the GIL I think, but in theory the work could rotate between threads). The main thread will return to the interactive REPL right away, so you can type in other stuff while the executor's worker threads are printing stuff the background (I suggest running pool.shutdown() to make them stop). This is fine.

But if the example code is run as a script, you'll usually get "MainThread", followed by exactly four repeats of "ThreadPoolExecutor-0_0" (or fewer in the unlikely case that the race condition strikes you). That's the number of threads the ThreadPoolExecutor was limited to, but note that the thread name that gets printed will usually end with 0 every time (you don't get one output from each worker thread, just the same number of outputs as there are threads, all from the first thread). Why you get that number of outputs (instead of zero or one or an infinite number) was one part of the Stack Overflow question.

The answer turned out to be that after the main thread has queued up the first job in the ThreadPoolExecutor, it runs off the end of the script's code, so it starts shutting down the interpreter. The cleanup function _python_exit (in Lib/concurrent/futures/thread.py) gets run since it is registered with atexit, and it tries to signal the worker threads to shut down cleanly. However, the shutdown logic interacts oddly with an executor that's still spinning up its threads. It will only signal and join the threads that existed when it started running, not any new threads.

As it turns out, usually the newly spawned threads will shut themselves down immediately after they spawn, but as a side effect, the first worker thread carries on longer than expected, doing one additional job for each new thread that gets spawned and exiting itself only when the executor has a full set. This is why there are four outputs from the worker thread instead of some other number. But the exact behavior is dependent on the thread scheduling order, so there is a race condition.

You can demonstrate a change in behavior from different timing by putting a call to time.sleep at the very top of the _worker() function (delaying how quickly the new threads can get to the work queue). You should see the program behavior change to only print "ThreadPoolExecutor-0_0" once before exiting.

Lets go through the steps of the process:

1. The main thread runs f() and schedules a job (which adds a work item to the executor's work queue). The first worker thread is spawned by the executor to run the job, since it doesn't have any threads yet. The main thread also sets a callback on the future to run f() again.

2. The main thread exits f() and reaches the end of the script, so it begins the interpreter shutdown process, including calling atexit functions. One of those is _python_exit, which adds a reference to None to the executor's work queue. Note that the None is added *after* the job item from step 1 (since they're both done by the same main thread). It then calls join() on the worker thread spawned in step 1, waiting for it to exit. It won't try to join any other threads that spawn later, since they don't exist yet.

3. The first worker thread spawned by the executor in step 1 begins running and pops an item off the work queue. The first item is a real job, so it runs it. (The first parts of this step may be running in parallel with step 2, but completing job will take much longer than step 2, so the rest of this step runs by itself after step 2 has finished.) Eventually the job ends and the callback function on the Future is called, which schedules another job (putting a job item in the queue after the None), and spawning a second worker thread (since the executor doesn't have enough yet).

4. The race condition occurs here. Usually the new worker thread (created in step 3) starts running next and pops the None off of the work queue (leaving the a real work item still in the queue). It checks and finds the the global _shutdown flag is set, so it adds another None to the job queue (at the end again) and quits.

5. The other half of the race is here. The first worker finishes the callback and is done with the first job, so it goes back to the work queue for another one. It usually finds the real job it scheduled in step 3 (since the None was already taken by the other thread in step 4). From then on, the code repeats the behavior from step 3 (doing the job, calling the callback, queuing a new job, and spawning a new thread since the executor still isn't at full capacity).

6. Steps 4 and 5 will repeat a few more times until the executor has as many threads as it wants. If no new thread is spawned at the end of step 5, the first worker thread finally gets to pop a None from the queue instead of a job, so it will shut down. This lets the the main thread, which has been blocked since step 2, finally finish it's join() and shut down the rest of the interpreter.

The race condition occurs between steps 4 and 5. If the first worker thread (that usually runs step 5) reaches the work queue before the other worker thread (which usually runs step 4), the first worker thread will get the None instead of the new thread. Thus the first worker will shut down earlier that in the usual scenario described above. The second thread (or third or fourth, depending on which cycle of steps 4 and 5 we're on) could get the job off the queue and start working on it while the first thread is exiting. That would be fine, but when the first thread exits, it will unblock the main thread and the interpreter will continue shutting down. This could cut the ground out from under the code running in the remaining worker thread.

One solution would be to avoid creating any new threads when the interpreter is in the process of shutting down. We can check for the global _shutdown variable inside ThreadPoolExecutor._adjust_thread_count, though I think it needs a lock to avoid another race condition (where _shutdown and the contents of _thread_queues are accessed out of sync, e.g. a race between steps 2 and 3 above that could only occur if the jobs were exceedingly fast to complete).

There are other options though. We could make it an error to queue up new work to an executor when the interpreter is in the process of shutting down (just change the "if self._shutdown" test in ThreadPoolExecutor.submit to also look at the global _shutdown variable, and the worker thread will crash with a RuntimeError just before things shut down). Or we could change the behavior of the workers to shut down as soon as possible rather than finishing all queued work items (remove the continue from the inner block in the loop in _worker so that it always checks the global _shutdown after completing each job). Or another option might be to change the cleanup logic in _python_exit to double check for additional threads to join() after it finishes waiting on its first set.

----------
components: Library (Lib)
messages: 304364
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: Race condition in ThreadPoolExecutor when scheduling new jobs while the interpreter shuts down
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31783>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:34:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 21:34:15 +0000
Subject: [issue31784] Add time.time_ns(): get time with nanosecond resolution
Message-ID: <1507930455.75.0.213398074469.issue31784@psf.upfronthosting.co.za>


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

time.time() returns time as a float, but the conversion to float lose precision at the nanosecond resolution.

I propose to add a new time.time_ns() function which returns time as an integer number of nanoseconds since epoch. It's similar to the st_mtime_ns field of os.stat_result which extended the old st_mtime field.

For the full rationale, see my thread on python-ideas:
[Python-ideas] Add time.time_ns(): system clock with nanosecond resolution
https://mail.python.org/pipermail/python-ideas/2017-October/047318.html

----------
components: Library (Lib)
messages: 304365
nosy: haypo
priority: normal
severity: normal
status: open
title: Add time.time_ns(): get time with nanosecond resolution
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31784>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:34:33 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 21:34:33 +0000
Subject: [issue31765] BUG: System deadlocks performing big loop operations in
 python 3.5.4, windows 10
In-Reply-To: <CACv8_d82W8AYy961pnw8S-3pu3YHmsNfcp_5YW2y+43hPYUK0g@mail.gmail.com>
Message-ID: <1507930473.04.0.213398074469.issue31765@psf.upfronthosting.co.za>


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

Nikhil, I am closing this for now because I am at least 85% sure David is right.  To get any help, you need to reduce your code to the minimum needed to produce the symptoms and then include that with any question.  You would be told the same on Stackoverflow, which is another place to seek answers.

----------
nosy: +terry.reedy
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31765>
_______________________________________

From report at bugs.python.org  Fri Oct 13 17:35:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Oct 2017 21:35:12 +0000
Subject: [issue31784] Add time.time_ns(): get time with nanosecond resolution
In-Reply-To: <1507930455.75.0.213398074469.issue31784@psf.upfronthosting.co.za>
Message-ID: <1507930512.97.0.213398074469.issue31784@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3965
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31784>
_______________________________________

From report at bugs.python.org  Fri Oct 13 18:03:44 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 22:03:44 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1507932224.7.0.213398074469.issue31778@psf.upfronthosting.co.za>


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

It has been some time since literal_eval literally only evaluated literals.  'constant_eval' might be a better name now, with the proviso of 'safely, in reasonable time'.

>>> from ast import literal_eval as le
>>> le('(1,2,3)')
(1, 2, 3)
>>> le('(1,2, (3,4))')
(1, 2, (3, 4))

I believe there was once a time when a simple tuple would be evaluated, while a nested one would not be.

"It is not capable of evaluating arbitrarily complex expressions, for example involving operators or indexing."  I do not read this as prohibiting all operators, but rather that now all will be accepted.

>>> le(2**2)
...
ValueError: malformed node or string: 4

Exponentiation of ints can take exponential time and can be used for denial of service attacks.

>>> le('2017-10-10')
1997

This is correct.  For '2017-10-10' to be a string representing a date, it must be quoted as a string in the code.

>>> le("'2017-10-10'")
'2017-10-10'

Rolling back previous enhancements would break existing code, so a deprecation period would be required.  But I would be inclined to instead update the doc to match the updated code better.  Lets see what others think.

----------
nosy: +benjamin.peterson, brett.cannon, ncoghlan, terry.reedy, yselivanov
type: behavior -> enhancement
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Fri Oct 13 19:08:21 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Oct 2017 23:08:21 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1507936101.25.0.213398074469.issue31780@psf.upfronthosting.co.za>


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

The formatting part of PEP 515 was implemented in #27080.  Chris Angelico's initial patch https://bugs.python.org/file44152/underscores_decimal_only.patch was, as the name says, for decimal only, and added "or '_' " to the error message.  The next patch added other bases but neglected to remove the obsoleted addition.

Chris, can you do a PR?  I don't think any new test is needed.  I would also be inclined to skip the news blurb, but since Eric should review and merge, it is his call.

----------
components: +Interpreter Core
nosy: +Rosuav, terry.reedy
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Fri Oct 13 19:25:16 2017
From: report at bugs.python.org (pdox)
Date: Fri, 13 Oct 2017 23:25:16 +0000
Subject: [issue31622] Make threading.get_ident() return an opaque type
In-Reply-To: <1506645572.33.0.213398074469.issue31622@psf.upfronthosting.co.za>
Message-ID: <1507937116.45.0.213398074469.issue31622@psf.upfronthosting.co.za>


pdox <pdox at alum.mit.edu> added the comment:

I don't see much enthusiasm or agreement here, so I'm closing for now.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31622>
_______________________________________

From report at bugs.python.org  Fri Oct 13 19:58:25 2017
From: report at bugs.python.org (pdox)
Date: Fri, 13 Oct 2017 23:58:25 +0000
Subject: [issue31785] Move instruction code blocks to separate file
Message-ID: <1507939104.79.0.213398074469.issue31785@psf.upfronthosting.co.za>


New submission from pdox <pdox at alum.mit.edu>:

I'd like to move all instruction code (the code inside a TARGET(NAME) block) from Python/ceval.c to a new file, Python/instructions.h. The new file will contain only instruction bodies (prefixed by related helper functions/macros).

Eval-context macros (e.g. TARGET, DISPATCH, TOP, PUSH, POP, etc) will not be moved to instructions.h, but will be expected to be available (defined by the #includer).

ceval.c will define the eval-context macros in the same way, and #include "instructions.h", inside the body of _PyEval_EvalFrameDefault. The code emitted should remain exactly the same.

The benefit of this change, is that it becomes easy to produce alternative implementations of EvalFrame which reuse the same instruction code, but with changes to the evaluation context or dispatch mechanism. In particular, after this change, I hope to experiment with adding a cross-platform subroutine-threading code evaluator. (for performance testing)

----------
components: Interpreter Core
messages: 304370
nosy: pdox
priority: normal
severity: normal
status: open
title: Move instruction code blocks to separate file
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31785>
_______________________________________

From report at bugs.python.org  Fri Oct 13 20:01:12 2017
From: report at bugs.python.org (pdox)
Date: Sat, 14 Oct 2017 00:01:12 +0000
Subject: [issue31785] Move instruction code from ceval.c to a separate file
In-Reply-To: <1507939104.79.0.213398074469.issue31785@psf.upfronthosting.co.za>
Message-ID: <1507939272.5.0.213398074469.issue31785@psf.upfronthosting.co.za>


Change by pdox <pdox at alum.mit.edu>:


----------
title: Move instruction code blocks to separate file -> Move instruction code from ceval.c to a separate file

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31785>
_______________________________________

From report at bugs.python.org  Sat Oct 14 00:05:31 2017
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 14 Oct 2017 04:05:31 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507953931.62.0.213398074469.issue30744@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

Guido: you must be tired and forgot that locals() is a regular function :-)  The compiler cannot recognize it reliably.  Moreover, if f_locals can be modified outside a tracing hook, then we have the same problem in a cross-function way, e.g. if function f1() calls function f2() which does sys._getframe(1).f_locals['foo'] = 42.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Oct 14 00:22:19 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 04:22:19 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1507954939.97.0.213398074469.issue31742@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, I'll head down the path of creating a new procedural PEP to supersede PEP 411 (I'll try to get the locals() semantic clarification PEP out of the way first, though).

I'll make "Where to put the feature flags?" an open question, as my rationale for proposing __main__ was three-fold:

1. In regular scripts, it makes feature flags as easy to set as possible, since you can just do "use_provisional_interpreters = True" without any import at all
2. In applications, "import __main__; use_provisional_interpreters = True" isn't markedly more brittle as a process-global state storage location than any other module name (as long as the feature flag names are prefixed to minimise the risk of name collisions)
3. Using an existing always imported module makes the runtime cost of managing the feature flags as close to zero as possible

However, you'd also get most of those benefits with an even lower risk of name collisions by co-opting "sys" for the same purpose.

Silencing the warning via the feature flag:

    import sys
    sys.use_provisional_interpreters = True
    import interpreters


Silencing the warning via the warnings module:

    from warnings import filterwarnings
    filterwarnings("ignore", module="interpreters", category=FutureWarning)
    import interpreters

Emitting the warning:

    import sys
    _feature_flag = f"use_provisional_{__name__}"
    if not getattr(sys, _feature_flag):
        import warnings
        _provisional_msg = (
            f"The {__name__} module is currently a provisional API - see documentation for details. "
            f"Set 'sys.{_feature_flag} = True' before importing the API to disable this warning."
        )
        warnings.warn(FutureWarning, _provisional_msg)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Sat Oct 14 00:33:41 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 04:33:41 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1507955621.54.0.213398074469.issue31772@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, I think that check would make the most sense, since the bytecode invalidation check is "_r_long(raw_timestamp) != source_mtime" (to allow for things like version control operations that send source timestamps backwards).

A test for that could then just mock time.time() to make sure it returned  a time matching the source mtime, and checked that the bytecode wasn't written.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:05:42 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 05:05:42 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1507957542.17.0.213398074469.issue31778@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm marking this as documentation issue for now, as the operators that literal_eval allows are solely those where constant folding support is needed to correctly handle complex and negative numbers (as noted in the original post):

```
>>> dis.dis("+1")
  1           0 LOAD_CONST               1 (1)
              2 RETURN_VALUE
>>> dis.dis("-1")
  1           0 LOAD_CONST               1 (-1)
              2 RETURN_VALUE
>>> dis.dis("1+1")
  1           0 LOAD_CONST               1 (2)
              2 RETURN_VALUE
>>> dis.dis("1+1j")
  1           0 LOAD_CONST               2 ((1+1j))
              2 RETURN_VALUE
>>> dis.dis("2017-10-10")
  1           0 LOAD_CONST               3 (1997)
              2 RETURN_VALUE
```

So the key promise that literal_eval makes is that it will not permit arbitrary code execution, but the docs should make it clearer that it *does* permit constant folding for addition and subtraction in order to handle the full range of numeric literals.

If folks want to ensure that the input string *doesn't* include a binary operator, then that currently needs to be checked separately with ast.parse:

```
>>> type(ast.parse("2+3").body[0].value) is ast.BinOp
True
>>> type(ast.parse("2017-10-10").body[0].value) is ast.BinOp
True
```

For 3.7+, that check could potentially be encapsulated as an "allow_folding=True" keyword-only parameter (where the default gives the current behaviour, while "allow_folding=False" disables processing of UnaryOp and BinOp), but the docs update is the more immediate need.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:14:32 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 05:14:32 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507958072.56.0.213398074469.issue31757@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:19:47 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 05:19:47 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507958387.83.0.213398074469.issue31757@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I update the example in "First Steps Towards Programming" to match the one in "Defining Functions" (which is also shown on the home page at www.python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:22:05 2017
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 14 Oct 2017 05:22:05 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507958525.71.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 7060380d577690a40ebc201c0725076349e977cd by INADA Naoki in branch '3.6':
bpo-31672: Fix string.Template accidentally matched non-ASCII identifiers (GH-3872)
https://github.com/python/cpython/commit/7060380d577690a40ebc201c0725076349e977cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:45:03 2017
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 14 Oct 2017 05:45:03 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507959903.22.0.213398074469.issue31672@psf.upfronthosting.co.za>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +3966

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:48:37 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 05:48:37 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507960117.07.0.213398074469.issue31757@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3967
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Sat Oct 14 01:56:17 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 05:56:17 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507960577.9.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, my current goal is to see if I can come up with a surgical fix that solves the established problem with the bad interaction between cells and trace functions without any unintended consequences for either CPython or other interpreters.

That means the only behaviours I actually *want* to change are those that are pretty clearly quirky at best, and outright bugs at worst:

- registering a trace function can result in closure state being reset inappropriately, even when none of the code involved accesses locals() or f_locals
- registering a trace function may lead to changes to locals() made outside the trace function nevertheless being written back to the actual frame state

Establishing a write-through proxy for cell references is definitely fine - allowing shared access to closure state is the whole reason we have cell objects in the first place.

The more complex case is with regular locals since:

- they used to be regular dictionaries in 1.x, but one of the early 2.x releases deliberately changed their semantics with the introduction of fast locals
- people *do* sometimes treat the result of locals() at function scope as a regular dictionary, and hence they don't always copy it before mutating it and/or returning a reference to it
- f_locals is accessible from outside the running function/generator/coroutine, so compilers can't just key off calls to locals() inside the function to decide whether or not they can see all changes to local variables
- looking for calls to locals() at compile time is dubious anyway, since the builtin may have been aliased under a different name (we do something like that for zero-arg super(), but that breaks far more obviously when the use of name aliasing prevents the compiler from detecting that you need a __class__ reference compiled in)
- trace functions nevertheless still need to be able to write their changes back to the function locals in order for debuggers to support value injection

My latest design concept for the trace proxy thus looks like this (I've been iterating on design ideas to try to reduce the potential memory impact arising from merely installing a trace function):

1. The core proxy behaviour would be akin to wrapping f_locals in types.MappingProxyType (and I expect the new proxy will be a subclass of that existing type, with the tentative name "_FunctionLocalsProxy")

2. The currently planned differences consist of the following:
- setting and deleting items is supported
- holding a reference back to the originating frame (to allow for lazy initialisation of the extra state only if the local variables are actually mutated through the proxy)
- when a cell variable is mutated through the proxy, the cell gets added to a lazily constructed mapping from names to cells (if it isn't already there), and the value in the cell is also modified
- when a local variable is mutated through the proxy, it gets added to a set of "pending writebacks"

The post-traceback frame update in the trampoline function would then write back only the locals registered in "pending writebacks" (i.e. only those changes made through the proxy, *not* any incidental changes made directly to the result of locals()), which would allow this change to reduce the potential local state manipulation side effects of registering a trace function.

If actual implementation shows that this approach faces some technical hurdle that makes it infeasible in practice, then I agree it would make sense for us to look at alternatives with higher risks of unwanted side effects. However, based on what I learned while writing the first draft of PEP 558, I'm currently fairly optimistic I'll be able to make the idea work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:05:55 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 06:05:55 +0000
Subject: [issue31785] Move instruction code from ceval.c to a separate file
In-Reply-To: <1507939104.79.0.213398074469.issue31785@psf.upfronthosting.co.za>
Message-ID: <1507961155.92.0.213398074469.issue31785@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

While I can see the utility for experimentation, I think the proposed change would make our lives more difficult.  The body inside the instruction blocks is central to the understanding of ceval.c and somewhat tightly coupled with it.  I would find it more difficult to maintain that code, switching back and forth between ceval.c and instructions.h.   We've already hit a level of complexity that presents a challenge to newcomers.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31785>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:08:20 2017
From: report at bugs.python.org (David Bieber)
Date: Sat, 14 Oct 2017 06:08:20 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1507961300.86.0.213398074469.issue31778@psf.upfronthosting.co.za>


David Bieber <dbieber at google.com> added the comment:

# Replies

> Rolling back previous enhancements would break existing code.

I sympathize completely with the need to maintain backward compatibility. And if this is the reason that this issue gets treated only as a documentation issue, rather than as a behavior issue, I can appreciate that.

If that is the case and literal_eval is not going to only evaluate literals, then for my use case I'll need a way to determine from a string whether it represents a literal. I can implement this myself using ast.parse and walking the resulting tree, looking for non-literal AST nodes. Would such an "is_literal" function would be more appropriate in the ast module than as a one-off function in Python Fire?

> The key promise that literal_eval makes is that it will not permit arbitrary code execution.

I disagree that this is the only key promise, and here's my reasoning. The docstring has two sentences, and each one makes a promise:
1. "Safely evaluate an expression node or a string containing a Python expression."
2. "The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and None."
(1) says that evaluation is safe -- this is the key promise that you reference. (2) is also a promise though, that only certain types are allowed. While one could argue that the behavior of the function is not specified for inputs violating that criteria, I think the clear correct thing to do is to raise a ValueError if the value doesn't meet the criteria. This is what was done in Python 2, where the docstring for literal_eval is these same two sentences (modulo the inclusion of bytes and sets). It's my opinion that Python 2's behavior better matches the docstring as well as the behavior implied by the function's name.


# Additional observations
1. Python 2 _does_ support parsing complex literals, but does not support treating e.g. '1+1' as a literal.
ast.literal_eval('1+1j') # works in both Python 2 and Python 3
ast.literal_eval('1j+1') # raises a ValueError in Python 2, returns 1+1j in Python 3
ast.literal_eval('1+1') # raises a ValueError in Python 2, returns 2 in Python 3

2. Python 3 supports parsing addition and subtraction at any level of nesting.
ast.literal_eval('(1, (0, 1+1+1))') # raises a ValueError in Python 2, returns (1, (0, 3)) in Python 3

In my opinion, Python 2's behavior is correct in these situations since it matches the documentation and only evals literals as defined in the documentation.

# Source
The relevant code in Python 2.7.3 is [here](https://github.com/enthought/Python-2.7.3/blob/69fe0ffd2d85b4002cacae1f28ef2eb0f25e16ae/Lib/ast.py#L67). It explicitly allows NUM +/- COMPLEX, but not even COMPLEX +/- NUM. The corresponding code for Python 3 is [here](https://github.com/python/cpython/blob/ef611c96eab0ab667ebb43fdf429b319f6d99890/Lib/ast.py#L76). You'll notice it supports adding and subtracting arbitrary numeric types (int, float, complex).


---

Thanks for your replies and for hearing me out on this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:10:26 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 06:10:26 +0000
Subject: [issue31763] Add NOTICE level to the logging module
In-Reply-To: <1507747705.55.0.213398074469.issue31763@psf.upfronthosting.co.za>
Message-ID: <1507961426.52.0.213398074469.issue31763@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking as rejected/closed for the reasons cited in Issue 31732.  In particular, see Vinay Sajip's commentary in https://bugs.python.org/msg304318 where he notes that it was a specific design decision to not emulate syslog(3) in this regard.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31763>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:18:40 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 14 Oct 2017 06:18:40 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507961920.75.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

@Nick:
> We're OK with the idea that installing a trace function might automatically turn off various compiler and interpreter managed optimisations

We're OK with assigning to locals() doing that too.

> What we're aiming to avoid is requiring that implementations make the assertion in "a = 1; locals('a') = 2; assert a == 2" pass at function scope, and if anything, we'd prefer to make it a requirement for that assertion to *fail*.

Why do you want it to fail? Given that it's already guaranteed to pass in some scopes (definitely in CPython, I'm not sure if it's in the language spec), and that we need to support mutations of f_locals for debugging, then this seems like a quixotic requirement. But if we do want it to fail, then we should make it fail obviously, e.g. by having locals() return a read-only mapping that raises an exception on mutation.

The only rationale I can understand here is the desire to leave options open for alternative implementations... but in practice all those alternative implementations can either support this just fine (because they have to to support pdb), or else they're MicroPython and have already stopped supporting locals() entirely so it hardly matters how CPython tweaks the details of the semantics.

> Requiring locals to actually *be* a write-through proxy (for all locals, not just cell references) would revert Python's semantics to the state they were in before the "fast locals" concept was first introduced, and we have no intention of going back there.

Why not? I don't think anyone has ever suggested that "fast locals" made Python's *semantics* simpler.

@Armin:
> Perhaps more importantly, I am sure that if Python starts supporting random mutation of locals outside tracing hooks, then it would open the door to various hacks that are best not done at all, from a code quality point of view.

I'm not saying that assigning to locals() is great style, but there are totally legitimate use cases (debugging), and there's nothing stopping those hacks right now. You *can* use tracing hooks, or there's this nonsense: https://gist.github.com/njsmith/2347382

Once Python commits to supporting something, then generally it exposes it in a pretty straightforward way; it's really unusual to put the feature in a non-obvious place and then make the obvious way subtly broken to punish people who try to use it.

@Nick
> - when do we update ordinary local variables? (this isn't broken, so we want to avoid changing it)

But as pointed out earlier in this thread, pdb's support for updating ordinary local variables *is* currently broken, and would be fixed by using a write-through proxy for f_locals: https://bugs.python.org/issue30744#msg297480

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:55:09 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 14 Oct 2017 06:55:09 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1507964109.42.0.213398074469.issue31780@psf.upfronthosting.co.za>


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

I agree there's no need for tests, since we usually don't guarantee such messages going forward. Also, I think skipping the news blurb is reasonable for this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:57:38 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 14 Oct 2017 06:57:38 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1507964258.95.0.213398074469.issue31455@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
pull_requests: +3968

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Oct 14 02:58:54 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 14 Oct 2017 06:58:54 +0000
Subject: [issue31455] ElementTree.XMLParser() mishandles exceptions
In-Reply-To: <1505323719.65.0.33849698499.issue31455@psf.upfronthosting.co.za>
Message-ID: <1507964334.7.0.213398074469.issue31455@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Backport PR for 2.7 added: 3992

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31455>
_______________________________________

From report at bugs.python.org  Sat Oct 14 03:03:53 2017
From: report at bugs.python.org (pdox)
Date: Sat, 14 Oct 2017 07:03:53 +0000
Subject: [issue31785] Move instruction code from ceval.c to a separate file
In-Reply-To: <1507939104.79.0.213398074469.issue31785@psf.upfronthosting.co.za>
Message-ID: <1507964633.6.0.213398074469.issue31785@psf.upfronthosting.co.za>


pdox <pdox at alum.mit.edu> added the comment:

rhettinger, helper functions used by the instruction code would also be moved into instructions.h (e.g. call_function, do_call_core, cmp_outcome, etc). Done properly, there should be very little need to move between instructions.h and ceval.c to understand what is happening.

The contract between the two files has to be very explicit. The only dependencies instructions.h would have on ceval.c would be to receive the evaluator macros (for manipulating the stack & locals, flow control, triggering error condition, etc). A strict (non-leaky) abstraction interface is necessary for being able to re-use the instruction code in an alternate evaluator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31785>
_______________________________________

From report at bugs.python.org  Sat Oct 14 03:17:49 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Sat, 14 Oct 2017 07:17:49 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1507965469.71.0.213398074469.issue31754@psf.upfronthosting.co.za>


Change by Aniket Vyas <vyas45 at gmail.com>:


----------
keywords: +patch
pull_requests: +3969
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sat Oct 14 03:29:47 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Sat, 14 Oct 2017 07:29:47 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1507966187.19.0.213398074469.issue31754@psf.upfronthosting.co.za>


Aniket Vyas <vyas45 at gmail.com> added the comment:

Thanks Mariatta. I have initiated a PR for the issue. 

https://github.com/python/cpython/pull/3993

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sat Oct 14 03:30:29 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 07:30:29 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1507966229.13.0.213398074469.issue31334@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> patch review
versions:  -Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Sat Oct 14 03:51:52 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 07:51:52 +0000
Subject: [issue9633] pdb go stack up/down
In-Reply-To: <1282133837.82.0.171010459939.issue9633@psf.upfronthosting.co.za>
Message-ID: <1507967512.24.0.213398074469.issue9633@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9633>
_______________________________________

From report at bugs.python.org  Sat Oct 14 04:07:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 08:07:08 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
Message-ID: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

According to the documentation select.poll.poll() is blocked for infinite timeout if the timeout argument is negative. But due to rounding it is possible that timeout < 0, but an integer ms passed to the poll() syscall is 0, and poll() is not blocked.

----------
components: Extension Modules
messages: 304386
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: In select.poll.poll() ms can be 0 if timeout < 0
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sat Oct 14 04:14:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 08:14:32 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507968872.46.0.213398074469.issue31714@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cd195e2a7ac5c9b2574d5462752b7939641de4a9 by Serhiy Storchaka in branch 'master':
bpo-31714: Improved regular expression documentation. (#3907)
https://github.com/python/cpython/commit/cd195e2a7ac5c9b2574d5462752b7939641de4a9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Sat Oct 14 04:42:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 08:42:46 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507970566.72.0.213398074469.issue31714@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +3970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Sat Oct 14 05:12:29 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 09:12:29 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1507972349.81.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The current pdb misbehaviour when navigating the stack is indeed a valid argument in favour of allowing immediate write-through from trace functions for regular local variables as well - I don't recall reading that bug report when Xavier first linked to it, so thanks for bringing it up again.

Another useful point that bug report highlights is that one of the assumptions I'd been making (that typical trace hooks would only need to manipulate the frame they were called for) is incorrect: via frame.f_back, the trace hook also has access to all of the parent frames, so any delayed write-back based approach would need to traverse the whole call stack to be truly robust. At that point, granting trace functions access to a write-through proxy as f_locals for *every* frame starts looking like a far more attractive option.

This suggests to me that rather than only switching behaviours while the traceback function is running, we would instead need to make it so that we check for whether or not a trace function is installed for the process whenever f_locals is looked up. If it is, and the frame uses fast locals, then f_locals will be a _FunctionLocalsProxy instance. Otherwise, it will be a regular dictionary.

Making a dynamic decision on whether to return a proxy or not is needed to handle the pdb stack traversal use case properly: debuggers are often going to be confronted with frames that were created *before* their trace hook was installed. Right now, as per the issue Xavier linked, attempted writes back to those don't tend to work properly (due to when and where the write-back happens), but dynamically upgrading to write-through proxies in the presence of a trace hook should help resolve that.

While that's a more pervasive change than what I was considering, I think the cited pdb bug provides a strong enough rationale to justify the related risk of unintended consequences.

Interestingly, I think it also gives us a way to reduce the degree to which installation of a trace hook affects the semantics of locals(): when f_locals on a frame is a _FunctionLocalsProxy instance, the locals() builtin can still bypass it and return the underlying dict. The difference between this and my earlier proposal for two different snapshot namespaces is that there'd still only be one snapshot, it's that f_locals would either reference it directly (the default state), or else via a write-through proxy (the "tracing mode" state).

I think that approach will give us the best possible outcome available:

* for code using locals(), the behaviour in non-tracing mode will be completely unchanged, and the semantic differences between tracing and non-tracing mode while a function is running will be reduced, since the post-trace-hook writeback code will be removed, and locals() itself never return a reference to the write-through proxy (only the underlying namespace snapshot). (There will still be some semantic differences, since the snapshot will be implicitly refreshed in tracing mode, whereas you have to call locals() explicitly to refresh it in non-tracing mode)

* for code using frame.f_locals, it will either behave the same as locals() if no tracing hook is installed when you retrieve a reference from the frame (again, no change from the status quo), *or* it will immediately write through to the active locals if a tracing hook *is* installed (replacing the current post-trace-hook writeback code)

(Note: if folks want to instead argue for the compatibility break option, you're going to have to write your own PEP, as I have zero plans to implement that myself, and will oppose it as a gratuitously unnecessary compatibility break if it does get proposed. Toggling this behaviour change on "Tracing or not?" won't be hard, and it ensures any  unforeseen negative outcomes will only impact situations that are currently broken anyway)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Oct 14 05:16:28 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 14 Oct 2017 09:16:28 +0000
Subject: [issue31787] various refleaks when calling the __init__() method of
 an object more than once
Message-ID: <1507972588.41.0.213398074469.issue31787@psf.upfronthosting.co.za>


New submission from Oren Milman <orenmn at gmail.com>:

Various __init__() methods don't decref (if needed) before assigning to fields
of the object's struct (i.e. assigning to `self->some_field`):
- _asyncio_Task___init___impl() (in Modules/_asynciomodule.c)
- _lzma_LZMADecompressor___init___impl() (in Modules/_lzmamodule.c)
- _bz2_BZ2Decompressor___init___impl() (in Modules/_bz2module.c)
- EVP_tp_init() (in Modules/_hashopenssl.c)
- property_init_impl() (in Objects/descrobject.c)
- cm_init() (in Objects/funcobject.c)
- sm_init() (in Objects/funcobject.c)

For example, _asyncio_Task___init___impl() does `self->task_coro = coro;`
instead of `Py_XSETREF(self->task_coro, coro);`.
Thus, the following code would result in at least one refleak:
import _asyncio
task = _asyncio.Task('foo')
task.__init__('foo')


I would open a PR to fix this soon.

----------
components: Extension Modules
messages: 304389
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: various refleaks when calling the __init__() method of an object more than once
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31787>
_______________________________________

From report at bugs.python.org  Sat Oct 14 05:17:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 09:17:21 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507972641.13.0.213398074469.issue31714@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 69ed5b61e7d2bdaf2dc6684061f737adc24a96ae by Serhiy Storchaka in branch '3.6':
[3.6] bpo-31714: Improved regular expression documentation. (GH-3907). (#3994)
https://github.com/python/cpython/commit/69ed5b61e7d2bdaf2dc6684061f737adc24a96ae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Sat Oct 14 05:26:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 09:26:57 +0000
Subject: [issue31714] Improve re documentation
In-Reply-To: <1507299732.49.0.213398074469.issue31714@psf.upfronthosting.co.za>
Message-ID: <1507973217.8.0.213398074469.issue31714@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31714>
_______________________________________

From report at bugs.python.org  Sat Oct 14 05:43:06 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 14 Oct 2017 09:43:06 +0000
Subject: [issue31787] various refleaks when calling the __init__() method of
 an object more than once
In-Reply-To: <1507972588.41.0.213398074469.issue31787@psf.upfronthosting.co.za>
Message-ID: <1507974186.6.0.213398074469.issue31787@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
keywords: +patch
pull_requests: +3971
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31787>
_______________________________________

From report at bugs.python.org  Sat Oct 14 05:52:54 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Oct 2017 09:52:54 +0000
Subject: [issue9633] pdb go stack up/down
In-Reply-To: <1282133837.82.0.171010459939.issue9633@psf.upfronthosting.co.za>
Message-ID: <1507974774.67.0.213398074469.issue9633@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that we're currently looking into this as something that could be potentially addressed by PEP 558 and any related changes to the way that function locals interact with trace hooks: https://bugs.python.org/issue30744#msg304388

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9633>
_______________________________________

From report at bugs.python.org  Sat Oct 14 08:22:45 2017
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 14 Oct 2017 12:22:45 +0000
Subject: [issue31672] string.Template should use re.ASCII flag
In-Reply-To: <1507029340.05.0.213398074469.issue31672@psf.upfronthosting.co.za>
Message-ID: <1507983765.35.0.213398074469.issue31672@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 073150db39408c1800e4b9e895ad0b0e195f1056 by INADA Naoki in branch 'master':
bpo-31672: doc: Remove one sentence from library/string.rst (GH-3990)
https://github.com/python/cpython/commit/073150db39408c1800e4b9e895ad0b0e195f1056


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31672>
_______________________________________

From report at bugs.python.org  Sat Oct 14 10:10:08 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Oct 2017 14:10:08 +0000
Subject: [issue31732] Add TRACE level to the logging module
In-Reply-To: <1507552161.59.0.213398074469.issue31732@psf.upfronthosting.co.za>
Message-ID: <1507990208.58.0.213398074469.issue31732@psf.upfronthosting.co.za>


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

I'm not arguing against the rejection, but I want to mention a point in relation to Raymond's statement "five levels have sufficed for a long and that the need for finer distinctions almost never arises in practice".  In thinking about my own codebase, I have only one project where I added a notice level, and none in which I currently have a TRACE level although I think I used it as described below in one during development.

If logging had had TRACE built in, I would have used it in almost every project I've written.  Instead, I squash everything into the DEBUG level, and that results in two things: overly verbose debug logs, and still having to go in and add extra temporary debug logging statements to debug hard problems.

I don't think this is a terrible thing.  The "pain" of it only once rose to the level where I added a TRACE level to my program. My point is that the lack of TRACE (or NOTICE) getting added to projects on a common basis, rather than meaning the need for the distinction "almost never arises", means instead that the need for them is less pressing than the small pain of adding them.

I will make one argument in favor of adding a TRACE level, but I don't know that it is enough to shift the balance.  That argument is that if I had a TRACE level built in, instead of adding and deleting extra temporary debug logging statements during a debugging cycle, I would add them at the TRACE level and *leave them in*, at least until I was ready to ship the code.  Not having to add and remove them, and then almost always end up re-adding and re-removing them, would speed up my debugging cycle by a non-trivial amount.  Why don't I add a TRACE level and do this?  It feels like too much of a pain "just to debug this", but then I wind up coming up against that decision again when working on the next bug, and the next..and each time it is too much of a pain to add TRACE "just for this bug".  

So, having TRACE built in might speed up debugging cycles, because programmers are lazy :)

Having made this conscious as a result of thinking about this issue, I may start adding TRACE to my projects more often :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31732>
_______________________________________

From report at bugs.python.org  Sat Oct 14 10:36:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 14:36:11 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507991771.54.0.213398074469.issue31757@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 8c26a34f93db7ae96b42bcce6b557437436c7721 by Raymond Hettinger in branch 'master':
bpo-31757: Make Fibonacci examples consistent (#3991)
https://github.com/python/cpython/commit/8c26a34f93db7ae96b42bcce6b557437436c7721


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Sat Oct 14 10:36:58 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 14:36:58 +0000
Subject: [issue31757] Tutorial: Fibonacci numbers start with 1, 1
In-Reply-To: <1507732819.98.0.213398074469.issue31757@psf.upfronthosting.co.za>
Message-ID: <1507991818.1.0.213398074469.issue31757@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31757>
_______________________________________

From report at bugs.python.org  Sat Oct 14 12:29:36 2017
From: report at bugs.python.org (Rick J. Pelleg)
Date: Sat, 14 Oct 2017 16:29:36 +0000
Subject: [issue31725] Turtle/tkinter: NameError crashes ipython with
 "Tcl_AsyncDelete: async handler deleted by the wrong thread"
In-Reply-To: <CADB7NfPoZqq2JzNFppWebQiSBssr4fyJB=fsq_OLguhtECoidw@mail.gmail.com>
Message-ID: <CADB7NfNpZ7tNBFqZXu-DHBWH5S_99DQE6tHzTssDynjFRpzz8A@mail.gmail.com>


Rick J. Pelleg <rickjpelleg at gmail.com> added the comment:

Sorry, all reproduction attempts failed, both in plain Python and in
iPython.
I guess you can close this for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31725>
_______________________________________

From report at bugs.python.org  Sat Oct 14 12:39:36 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 14 Oct 2017 16:39:36 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1507999176.11.0.213398074469.issue31758@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

According to Serhiy's advice (https://bugs.python.org/issue31455#msg304338),
this issue now also includes some crashes in _elementtree:


The following code crashes:
import _elementtree
parser = _elementtree.XMLParser.__new__(_elementtree.XMLParser)
parser.close()

This is because _elementtree_XMLParser_close_impl() assumes that the XMLParser
object is initialized, and so it passes `self` to expat_parse(), which assumes
that `self->parser` is valid, and crashes.
Similarly, calling feed(), _parse_whole() or _setevents(), or reading the
`entity` or `target` attribute of an uninitialized XMLParser object would
result in a crash.


ISTM that PR 3956 is more complex, and already not so small, so i would soon
open another PR to fix these crashes.

----------
title: various refleaks in _elementtree -> various refleaks in _elementtree, and crashes when using an uninitialized XMLParser object
type: resource usage -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sat Oct 14 13:31:29 2017
From: report at bugs.python.org (Alex Dzyoba)
Date: Sat, 14 Oct 2017 17:31:29 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1508002289.28.0.213398074469.issue14465@psf.upfronthosting.co.za>


Change by Alex Dzyoba <alex.dzyoba at gmail.com>:


----------
nosy: +alexdzyoba

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sat Oct 14 14:18:49 2017
From: report at bugs.python.org (Rick J. Pelleg)
Date: Sat, 14 Oct 2017 18:18:49 +0000
Subject: [issue31725] Turtle/tkinter: NameError crashes ipython with
 "Tcl_AsyncDelete: async handler deleted by the wrong thread"
In-Reply-To: <CADB7NfNpZ7tNBFqZXu-DHBWH5S_99DQE6tHzTssDynjFRpzz8A@mail.gmail.com>
Message-ID: <CADB7NfNqsUgQ8Tx3CKwMagOJKYvsv7xMfq-V=WecEA2s7j_N=g@mail.gmail.com>


Rick J. Pelleg <rickjpelleg at gmail.com> added the comment:

Just one more issue: since it happened before I found out that the "turtle"
package already has the pre-defined short version of commands, such as
"fd()", "lt()", etc., the crashed session included four function
definitions, for "fd()", "bk()", "lt()" and "rt()", in the form of:

def fd(val):

    forward(val)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31725>
_______________________________________

From report at bugs.python.org  Sat Oct 14 15:19:10 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 14 Oct 2017 19:19:10 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508008750.91.0.213398074469.issue30744@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

@Armin:
> Guido: you must be tired and forgot that locals() is a regular function :-)  The compiler cannot recognize it reliably.

I know, but we occasionally do make exceptions for builtins. In particular super() is recognized by the compiler.

@Everyone else:
I need to limit my screen time this weekend, hopefully you can either figure this out without my help -- there's no way I can keep up with this discussion. Sorry!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Oct 14 15:20:31 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 14 Oct 2017 19:20:31 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508008831.88.0.213398074469.issue30744@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> Moreover, if f_locals can be modified outside a tracing hook, then we have the same problem in a cross-function way, e.g. if function f1() calls function f2() which does sys._getframe(1).f_locals['foo'] = 42.

That's covered by the rule that says sys._getframe() has undefined results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Oct 14 15:42:49 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 14 Oct 2017 19:42:49 +0000
Subject: [issue31758] various refleaks in _elementtree,
 and crashes when using an uninitialized XMLParser object
In-Reply-To: <1507733619.97.0.213398074469.issue31758@psf.upfronthosting.co.za>
Message-ID: <1508010169.05.0.213398074469.issue31758@psf.upfronthosting.co.za>


Change by Oren Milman <orenmn at gmail.com>:


----------
pull_requests: +3972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31758>
_______________________________________

From report at bugs.python.org  Sat Oct 14 15:43:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Oct 2017 19:43:08 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1508010188.71.0.213398074469.issue31778@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The support of parsing addition and subtraction at any level of nesting was added by bc95973b51abadc84960e7836ce313f12cf515cf. The commit message and NEWS entry don't contain an issue number, thus the rationale of this change is not known. Raymond, could you please explain?

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Sat Oct 14 16:57:44 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Oct 2017 20:57:44 +0000
Subject: [issue31785] Move instruction code from ceval.c to a separate file
In-Reply-To: <1507939104.79.0.213398074469.issue31785@psf.upfronthosting.co.za>
Message-ID: <1508014664.11.0.213398074469.issue31785@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> A strict (non-leaky) abstraction interface is necessary 
> for being able to re-use the instruction code in an
> alternate evaluator.

The problem is that we don't have a strict (non-leaky) abstraction and I don't think we should impose one.

> Done properly, there should be very little need to move
> between instructions.h and ceval.c to understand what is happening.

I believe that is just wishful thinking and the separation will make it harder to learn and reason ceval.c.   Also, I really don't like putting the essential core of instruction code in a .h file rather than a .c file.

FWIW, when I've done my own experiments with alternative evaluation techniques (such as subroutine threading), it always required changes to the instruction bodies (in part because interesting variants use different argument passing techniques and in part because of a need to change state external to the instruction body for tracing and whatnot).

Overall, I think the proposal would be a net detriment to future maintenance and would not have a recurring payoff beyond your present experiments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31785>
_______________________________________

From report at bugs.python.org  Sat Oct 14 17:04:17 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Sat, 14 Oct 2017 21:04:17 +0000
Subject: [issue21263] test_gdb failures on os x 10.9.2
In-Reply-To: <1397674257.45.0.239061101467.issue21263@psf.upfronthosting.co.za>
Message-ID: <1508015057.81.0.213398074469.issue21263@psf.upfronthosting.co.za>


Aniket Vyas <vyas45 at gmail.com> added the comment:

Hi ! I am willing to take a look into this. I am pretty new to the community and would appreciate some pointers relating to the issue which can give me a head-start to resolving it. 

Thanks in advance !

----------
nosy: +vyas45

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21263>
_______________________________________

From report at bugs.python.org  Sat Oct 14 17:26:12 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Oct 2017 21:26:12 +0000
Subject: [issue17776] IDLE Internationalization
In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za>
Message-ID: <1508016372.63.0.213398074469.issue17776@psf.upfronthosting.co.za>


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

In the last few months, configdialog has been refactored to have a class for each settings tab.  This makes it easier to revise and add new options, such as 'menu language'.

With this done, the IDLE features implemented as (optional) extensions were turned into normal features.  Non-key option settings were moved to the General tab. The menu items were moved to mainmenu.py.  Having everything in one place should make translation easier.  When making further menu system changes, I will keep I18n in mind.

AFAIK, there is no runtime need to have 60+translation calls in the invisible mainmenu.menudefs structure, which would make it harder to read.  I would rather change the 'label=name' option in menu item insertion calls to 'label=_(name)' or 'label=gettext(name)' or possibly 'label=trandict[name].  In macosx the explicit "label='window'" would need the same change.  So would the scattered context menu insertion calls.

Just for translating the menu, gettext seems possibly like overkill.  I remain reluctance to use it without my questions above answered.  Another question: can the automatic selection mechanism be overridden by the user?

All that is needed is a simple template file that creates a translation dictionary  I think translation would be easiest if the template preserved both the order and hierarchical structure.  It would be trivial to write a function to create a full version of the following.

trandict = {
    'file': 
        '_New File':
        ...
    ...
}
[Note: top level names like 'file' are lowercased in menudefs but then capitalized in the menu.  Maybe they should be uppercased to start with.]

The output instead could match what whatever the gettext machinery requires.  I don't know if the gettext extractor preserves the order, but I am sure it will not preserve the structure.

Recently, translations were added to the official doc site.  A translation of the IDLE section should have a good-enough translation of the menu that can be extracted into a dict for IDLE.  The only problem is that they will not have the underscores for hot keys.  I don't know if these are universally used.

The Japanese translation includes the IDLE section.  The top level names (File, Edit, ... Help) are not tranlated.  Perhaps the team felt that such terms should be familiar enough to Japanese users to not need translation.  The dropdown menu labels *are* translated, but keep the English, as in
'New File [??????]'.     In any case, this is enough for experiments.

----------
assignee:  -> terry.reedy
versions: +Python 3.7 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17776>
_______________________________________

From report at bugs.python.org  Sat Oct 14 17:33:05 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Oct 2017 21:33:05 +0000
Subject: [issue17776] IDLE Internationalization
In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za>
Message-ID: <1508016785.44.0.213398074469.issue17776@psf.upfronthosting.co.za>


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

Ned> IDLE uses some Tk-supplied default menus and menu items

On Windows and *nix, the visible menu labels all come from IDLE.  I don't yet understand what is going on with Mac menus.  Some menu items call the tk file dialog, and the config highlight tab calls the color dialog, and these are localized however they are.  But that does not affect the menus.

Ned> So internationalization of IDLE would need to investigate and make use of Tk i18n features on all supported platforms.

Other than the dialogs mentioned above, (and the font dialog that is not used) I don't know what features you mean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17776>
_______________________________________

From report at bugs.python.org  Sat Oct 14 19:31:29 2017
From: report at bugs.python.org (Nitish)
Date: Sat, 14 Oct 2017 23:31:29 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508023889.77.0.213398074469.issue31780@psf.upfronthosting.co.za>


Change by Nitish <nitishchandrachinta at gmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sat Oct 14 19:55:59 2017
From: report at bugs.python.org (Semen Zhydenko)
Date: Sat, 14 Oct 2017 23:55:59 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
Message-ID: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>


New submission from Semen Zhydenko <simeon.zhidenko at gmail.com>:

completly must be changed to completely

----------
assignee: docs at python
components: Documentation
messages: 304405
nosy: Semen Zhydenko, docs at python
priority: normal
severity: normal
status: open
title: Typo in comments Modules/_ssl.c
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sat Oct 14 20:34:04 2017
From: report at bugs.python.org (Dan Snider)
Date: Sun, 15 Oct 2017 00:34:04 +0000
Subject: [issue31789] Better error message when failing to overload
 metaclass.mro
Message-ID: <1508027644.3.0.213398074469.issue31789@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

class meta(type):
    
    mros = (object,)
    
    def __new__(metacls, name, bases, namespace, fake_bases=()):
        print('entering __new__')
        metacls.fake_bases = fake_bases
        cls = type.__new__(metacls, name, bases, namespace)
        print('exiting __new__')
        return cls
    
    @staticmethod
    def mro(*args):
        print('entering mro')
        return meta.fake_bases + (object,)

class a(metaclass=meta, fake_bases=()): pass


That puts out the error message:

entering meta.__new__
entering meta.mro
Traceback (most recent call last):
  File "<pyshell#5948>", line 1, in <module>
    exec(code, u)
  File "<string>", line 14, in <module>
  File "<string>", line 6, in __new__
TypeError: super(type, obj): obj must be an instance or subtype of type


That doesn't at all explain why it doesn't work because super was never explicitly called. If the argument fake_bases isn't empty, or if mro isn't made a staticmethod/classmethod, it returns an appropriate message

TypeError: mro() returned base with unsuitable layout ('tuple')

----------
components: Interpreter Core
messages: 304406
nosy: bup
priority: normal
severity: normal
status: open
title: Better error message when failing to overload metaclass.mro
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31789>
_______________________________________

From report at bugs.python.org  Sat Oct 14 20:57:32 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 00:57:32 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508029052.94.0.213398074469.issue25588@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +3973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 21:26:52 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 01:26:52 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508030812.66.0.213398074469.issue25588@psf.upfronthosting.co.za>


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

As I reported on related #31761, importing autotest on Windows 10 has 3 errors with Python's shell and 4 with IDLE's, with two of those the same as the python shell failures.

IDLE can be detected in at least two ways.
>>> import sys; 'idlelib.run' in sys.modules
True
>>> type(sys.stdout).__name__ == 'PseudoOutputFile'
True

'test.autotest' in sys.modules" would detect that test.autotest is being run, whether in a Python or IDLE shell.

Running test.__main__ from an editor results in screwy behavior.  Running just 'import test.autotest' instead gives the same result.  I expected at least the latter to have the same result as when run in the shell.  Wrong.

First, there is an additional test failure.

0:00:12 [ 18/407] test_aifc
test test_aifc crashed -- Traceback (most recent call last):
  File "F:\dev\3x\lib\test\libregrtest\runtest.py", line 163, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "F:\dev\3x\lib\importlib\__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 680, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "F:\dev\3x\lib\test\test_aifc.py", line 9, in <module>
    import aifc
  File "F:\dev\3x\lib\aifc.py", line 254, in <module>
    from chunk import Chunk
ImportError: cannot import name 'Chunk' from 'chunk' (F:\Python\mypy\chunk.py)

Next, the tests run normallu up to
:03:18 [ 77/407/1] test_concurrent_futures

Then, while running test_configparser, the user process crashes, IDLE restarts a new user process, and the test suite restarts (in the IDLE process?) from the beginning, sending output to the console, not IDLE, and running each test 5 times.  This all is repeatable.  The following is the initial part of the console output.

== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== Windows-10-10.0.14393-SP0 little-endian
== cwd: F:\dev\3x\build\test_python_2056
== CPU count: 12
== Windows-10-10.0.14393-SP0 little-endian
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== cwd: F:\dev\3x\build\test_python_6020
== encodings: locale=cp1252, FS=utf-8
== CPU count: 12
== Windows-10-10.0.14393-SP0 little-endian
Run tests sequentially
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
== cwd: F:\dev\3x\build\test_python_272
0:00:00 [  1/407] test_grammar
== encodings: locale=cp1252, FS=utf-8
== CPU count: 12
== Windows-10-10.0.14393-SP0 little-endian
== CPython 3.7.0a1+ (heads/master:8c26a34f93, Oct 14 2017, 19:37:37) [MSC v.1900 32 bit (Intel)]
Run tests sequentially
== cwd: F:\dev\3x\build\test_python_7396
0:00:00 [  1/407] test_grammar
== Windows-10-10.0.14393-SP0 little-endian
== encodings: locale=cp1252, FS=utf-8
== CPU count: 12
== cwd: F:\dev\3x\build\test_python_13476
Run tests sequentially
== CPU count: 12
0:00:00 [  1/407] test_grammar
== encodings: locale=cp1252, FS=utf-8
== encodings: locale=cp1252, FS=utf-8
Run tests sequentially
Run tests sequentially
0:00:00 [  1/407] test_grammar
0:00:00 [  1/407] test_grammar
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
0:00:00 [  2/407] test_opcodes
[and so on]

I said 'crash' because the run process catches SystemExit.
>>> raise SystemExit
>>> 
I have ocassionally encountered unexpected restarts before, but never, that I remember, so easily repeatable.

----------
stage: patch review -> commit review
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 21:29:26 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 01:29:26 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508030966.49.0.213398074469.issue25588@psf.upfronthosting.co.za>


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

The README patch will finish this issue.  Fixing individual failures and investigating the crash will be new issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 21:31:17 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 01:31:17 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508031077.75.0.213398074469.issue25588@psf.upfronthosting.co.za>


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


New changeset 620f70eed615efde35517d7ae86354de3b2a0d03 by Terry Jan Reedy in branch 'master':
bpo-25588: Document autotest in idle_test/README.txt. (#4000)
https://github.com/python/cpython/commit/620f70eed615efde35517d7ae86354de3b2a0d03


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 21:36:34 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 01:36:34 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508031394.13.0.213398074469.issue25588@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +3974
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 22:35:19 2017
From: report at bugs.python.org (Pablo)
Date: Sun, 15 Oct 2017 02:35:19 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508034919.27.0.213398074469.issue31780@psf.upfronthosting.co.za>


Change by Pablo <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +3975
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sat Oct 14 22:57:08 2017
From: report at bugs.python.org (Pablo)
Date: Sun, 15 Oct 2017 02:57:08 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508036228.19.0.213398074469.issue31786@psf.upfronthosting.co.za>


Change by Pablo <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +3976
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sat Oct 14 23:17:00 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 03:17:00 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508037420.28.0.213398074469.issue25588@psf.upfronthosting.co.za>


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


New changeset 0fee56c86344386bde8486ab803f564cb8a5203b by Terry Jan Reedy in branch '3.6':
[3.6] bpo-25588: Document autotest in idle_test/README.txt. (GH-4000) (#4001)
https://github.com/python/cpython/commit/0fee56c86344386bde8486ab803f564cb8a5203b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 23:32:00 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 03:32:00 +0000
Subject: [issue25588] Run test suite from IDLE idlelib.run subprocess
In-Reply-To: <1447056283.03.0.330229894782.issue25588@psf.upfronthosting.co.za>
Message-ID: <1508038320.33.0.213398074469.issue25588@psf.upfronthosting.co.za>


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

Running the file containing 'import test.autotest' directly with python gives the test_aifc failure and the same bizarre behavior after test_concurrent_futures.  Testing restarts apparently in 5 parallel threads or processes.  The lines of output are the same though interleaved slightly differently.  The only difference is that the number in the 5 build/test_python_nnnn working directories are different. So, not an IDLE bug.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25588>
_______________________________________

From report at bugs.python.org  Sat Oct 14 23:41:16 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 03:41:16 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508038876.23.0.213398074469.issue31780@psf.upfronthosting.co.za>


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


New changeset 28773ca7a7aa58a28e42a9eb0066acf71b5a8dc4 by Terry Jan Reedy (Dargor) in branch 'master':
bpo-31780: Fix incorrect error message for ',x', ',b', ',o' specs (#4002)
https://github.com/python/cpython/commit/28773ca7a7aa58a28e42a9eb0066acf71b5a8dc4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sat Oct 14 23:41:28 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Oct 2017 03:41:28 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508038888.84.0.213398074469.issue31780@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3977

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sun Oct 15 00:01:30 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 04:01:30 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508040090.62.0.213398074469.issue31780@psf.upfronthosting.co.za>


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


New changeset 59b5c139d2ae95b1d1da63f81c3d777932215533 by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31780: Fix incorrect error message for ',x', ',b', ',o' specs (GH-4002) (#4004)
https://github.com/python/cpython/commit/59b5c139d2ae95b1d1da63f81c3d777932215533


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sun Oct 15 00:01:57 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Oct 2017 04:01:57 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508040117.71.0.213398074469.issue31780@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Sun Oct 15 00:13:11 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Oct 2017 04:13:11 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508040791.5.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Guido: any proposed semantic changes for CPython will eventually make their way through PEP 558 (and potentially a competing PEP if someone else is sufficiently keen on the idea of making non-tracing mode behave the same way as tracing mode), so ignoring the detailed blow-by-blow on this ticket should be fine.

If anything, it will make it easier for you to pick up any relevant details of the eventual rationale that the PEP text has missed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 15 00:18:22 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Oct 2017 04:18:22 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508041102.86.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Err, I phrased that last sentence really badly.

I meant that if Guido *hasn't* been following this ticket closely, he's more likely to ask for clarification if PEP 558 proposes a semantic change based on the discussion here without adequately justifying it in the PEP itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 15 01:06:28 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 15 Oct 2017 05:06:28 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1508041102.86.0.213398074469.issue30744@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK=ZgfZF5y3UN_jMz70GhQHsCoC2zw3B1C=Qc34oWu_tQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Sounds like a plan, I will ignore the ticket then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 15 01:06:47 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 15 Oct 2017 05:06:47 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508044007.21.0.213398074469.issue30744@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 15 01:19:56 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 15 Oct 2017 05:19:56 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1508044796.6.0.213398074469.issue31742@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

OK, I'll wait for the new PEP and ignore the ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Sun Oct 15 01:20:09 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 15 Oct 2017 05:20:09 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1508044809.04.0.213398074469.issue31742@psf.upfronthosting.co.za>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Sun Oct 15 02:00:32 2017
From: report at bugs.python.org (Zoltan Krajcsovics)
Date: Sun, 15 Oct 2017 06:00:32 +0000
Subject: [issue31790] double free or corruption (while using smem)
Message-ID: <1508047232.57.0.213398074469.issue31790@psf.upfronthosting.co.za>


New submission from Zoltan Krajcsovics <temezs at freemail.hu>:

Command executed when the crash happened:

/usr/bin/python /usr/bin/smem -t -c command pss -P /usr/lib/chromium/chromium

The attached error.log contains the backtrace and memory map printed.

This is a sporadic error, the command is called every second 0-24, and I got one such error after half a day of running. I probably had another after a few days, but I failed to save that one, so I am not sure, if they are really the same.

It would seem that using a more overloaded / older machine triggers the error more often, the machine I got it on was a

Hewlett-Packard HP Compaq dc7900 Small Form Factor/3031h, BIOS 786G1 v01.27 10/22/2015

The problem seems to have emerged after updating to Debian Stretch.

python version:
Python 2.7.13

smem version:
pool/main/s/smem/smem_1.4-2_all.deb
(could not get an internal smem version, only the debian package)

----------
components: Library (Lib)
messages: 304418
nosy: zulthan
priority: normal
severity: normal
status: open
title: double free or corruption (while using smem)
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31790>
_______________________________________

From report at bugs.python.org  Sun Oct 15 02:04:55 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Oct 2017 06:04:55 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508047495.06.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just confirming that the locals() vs frame.f_locals distinction also exists in the C API: the former is PyEval_GetLocals() (which implicitly ensures the snapshot is up to date), while the equivalent of the latter is direct access to frame->f_locals (and it's left to code accessing the field to decide whether it needs an up to date snapshot or not).

That means I'll be able to change what we store in frame->f_locals, while updating PyEval_GetLocals to check for a _FastLocalsProxy instance and return a reference to the underlying snapshot instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 15 02:22:29 2017
From: report at bugs.python.org (pdox)
Date: Sun, 15 Oct 2017 06:22:29 +0000
Subject: [issue31791] Ensure that all PyTypeObject fields are set to non-NULL
 defaults
Message-ID: <1508048549.34.0.213398074469.issue31791@psf.upfronthosting.co.za>


New submission from pdox <pdox at alum.mit.edu>:

Ensure that every function pointer in every PyTypeObject is set to a non-NULL default, to spare the cost of checking for NULL with every use. As a basic example, consider PyNumber_Negative:

PyObject *
PyNumber_Negative(PyObject *o)
{
    PyNumberMethods *m;

    if (o == NULL) {
        return null_error();
    }

    m = o->ob_type->tp_as_number;
    if (m && m->nb_negative)
        return (*m->nb_negative)(o);

    return type_error("bad operand type for unary -: '%.200s'", o);
}

If "tp_as_number" and "nb_negative" were always guaranteed non-NULL, then the function could omit the second if statement, and invoke the function pointer directly. To maintain the existing behavior, the default nb_negative function would be set to the following:

PyObject* nb_negative_default(PyObject *o) {
    return type_error("bad operand type for unary -: '%.200s'", o);
}

This removes two NULL-checks from the PyNumber_Negative. Many other operators and builtins would be able to benefit in the same way.

----------
components: Interpreter Core
messages: 304420
nosy: pdox
priority: normal
severity: normal
status: open
title: Ensure that all PyTypeObject fields are set to non-NULL defaults
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31791>
_______________________________________

From report at bugs.python.org  Sun Oct 15 02:33:10 2017
From: report at bugs.python.org (pdox)
Date: Sun, 15 Oct 2017 06:33:10 +0000
Subject: [issue31791] Ensure that all PyTypeObject fields are set to non-NULL
 defaults
In-Reply-To: <1508048549.34.0.213398074469.issue31791@psf.upfronthosting.co.za>
Message-ID: <1508049190.29.0.213398074469.issue31791@psf.upfronthosting.co.za>


pdox <pdox at alum.mit.edu> added the comment:

I believe it would also make sense to inline the 'as' structures (tp_as_async, tp_as_number, tp_as_sequence, tp_as_mapping, and tp_as_buffer), instead of having them be pointers. This would save one pointer dereference with each use. But this would have API compatibility consequences, so for this change it is off the table.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31791>
_______________________________________

From report at bugs.python.org  Sun Oct 15 02:59:30 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 06:59:30 +0000
Subject: [issue31791] Ensure that all PyTypeObject fields are set to non-NULL
 defaults
In-Reply-To: <1508048549.34.0.213398074469.issue31791@psf.upfronthosting.co.za>
Message-ID: <1508050770.07.0.213398074469.issue31791@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

1. This will increase the size of type object. Most types are not numbers, not collections and don't support the buffer protocol, thus save memory for tp_as_number, tp_as_sequence, tp_as_mapping and tp_as_buffer. This also can increase the time of type creation.

2. This will make harder testing that the particular protocol is supported (e.g. see PyIndex_Check or PyObject_CheckBuffer). And this will break any third-party code that does this directly, without using C API.

3. Calling function instead of executing inlined code after checking can increase stack consumption and slow down execution (see the usage of tp_descr_get).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31791>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:25:24 2017
From: report at bugs.python.org (pdox)
Date: Sun, 15 Oct 2017 07:25:24 +0000
Subject: [issue31791] Ensure that all PyTypeObject fields are set to non-NULL
 defaults
In-Reply-To: <1508048549.34.0.213398074469.issue31791@psf.upfronthosting.co.za>
Message-ID: <1508052324.28.0.213398074469.issue31791@psf.upfronthosting.co.za>


pdox <pdox at alum.mit.edu> added the comment:

serhiy.storchaka:

1) Where tp_as_number would normally be NULL, instead it would point to a fixed PyNumberMethods structure containing the default functions. This would make the memory increase negligible, as all non-number types would use the same structure.

2) If this is behavior we want to formally support, then we should provide macros for it. (all they must do is compare against the default pointer value, rather than NULL). Are there particular extension(s) you suspect may be doing this?

3) This has to be handled on a case-by-case basis. I would not remove inlined optimizations. If there are some fields that truly benefit from remaining NULL, those can be left alone. I would like to focus on the functions for which the common case (in code without type errors) is to make the indirect call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31791>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:31:38 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 07:31:38 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508052698.92.0.213398074469.issue31754@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 1b9e76ed3a055a53ca67397e928e1b408461900b by Berker Peksag (vyas45) in branch 'master':
bpo-31754: Fix type of 'itemsize' in PyBuffer_FillContiguousStrides (GH-3993)
https://github.com/python/cpython/commit/1b9e76ed3a055a53ca67397e928e1b408461900b


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:31:45 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Oct 2017 07:31:45 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508052705.9.0.213398074469.issue31754@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3978

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:34:44 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 07:34:44 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508052884.72.0.213398074469.issue31754@psf.upfronthosting.co.za>


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


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:37:09 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 07:37:09 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508053029.85.0.213398074469.issue31754@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset e881302b70ab36bafcf37e3917be118bbec97763 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31754: Fix type of 'itemsize' in PyBuffer_FillContiguousStrides (GH-3993)
https://github.com/python/cpython/commit/e881302b70ab36bafcf37e3917be118bbec97763


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:47:26 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 07:47:26 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508053646.25.0.213398074469.issue31754@psf.upfronthosting.co.za>


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


----------
stage: patch review -> backport needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:54:07 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 07:54:07 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508054047.28.0.213398074469.issue31788@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.4, Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 03:55:50 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 07:55:50 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508054150.78.0.213398074469.issue31788@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 04:18:48 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Oct 2017 08:18:48 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508055528.08.0.213398074469.issue31788@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +3979
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 05:35:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 09:35:58 +0000
Subject: [issue31792] test_buffer altered the execution environment
Message-ID: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

test_buffer adds two environment variables: 'OPENBLAS_MAIN_FREE': '1', 'GOTOBLAS_MAIN_FREE': '1'.

$ ./python -m test -v test_buffer
...
Warning -- os.environ was modified by test_buffer
  Before: (140174267697792, environ({...})
  After:  (140174267697792, environ({..., 'OPENBLAS_MAIN_FREE': '1', 'GOTOBLAS_MAIN_FREE': '1'}) 
test_buffer failed (env changed)

1 test altered the execution environment:
    test_buffer

Total duration: 8 sec
Tests result: SUCCESS

----------
components: Tests
messages: 304426
nosy: ezio.melotti, haypo, michael.foord, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: test_buffer altered the execution environment
type: resource usage
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 05:40:42 2017
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Oct 2017 09:40:42 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaXP4=NUjA=Yyjp-L1z-Up7+_+NWVYGsKMGSebbVkfsxg@mail.gmail.com>


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

I suggest to implement ROUND_UP in pytime and use it in all functions
accepting a timeout, not only poll. Search for ROUND_CEILING in the code to
find them. But functions accepting time like clock_settime() must continue
to use ROUND_CEILING.

Does someone want to work on such patch? The new rounding mode must be test
in test_time, you should just add the new mode at the top once if I recall
correctly.

---

select.poll currently uses ROUND_CEILING: round towards +infinity.

It looks like you would prefer ROUND_UP: round away from zero, right?

In the history of CPython, the rounding mode of functions accepting time,
timeout, duration, etc. changed many times, mostly because the C code
changed in subtle ways to fix different bugs. I mean that the exact
rounding mode wasn't really chosen on purpose. I'm now trying to get better
defined rouding modes in pytime, but it seems poll uses the wrong one.

https://haypo.github.io/pytime.html

I think that my problem is that I wanted to reuse the same rounding modes
for different use cases. It seems like clocks need ROUND_CEILING but
timeouts need ROUND_UP. Well, in the case of poll, the previous code before
moving to pytime was using ceil() which uses ROUND_CEILING.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sun Oct 15 05:41:42 2017
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Oct 2017 09:41:42 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbjPUzfncDbn3FoPMwUtkfneVAdYkYozUeR=GTXZKuEgQ@mail.gmail.com>


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

Why the env changed wasn't noticed before? Is it a recent change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 05:49:49 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 15 Oct 2017 09:49:49 +0000
Subject: [issue31793] Allow to specialize smart quotes in documentation
 translations
Message-ID: <1508060988.99.0.213398074469.issue31793@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

It would be great to allow each translation to specify their smart-quotes configuration, typically Japanese prefer no smart-quotes:

- https://github.com/python/docsbuild-scripts/issues/32

It's easily done by adding a Doc/docutils.conf file, I'm opening a PR.

----------
assignee: docs at python
components: Documentation
messages: 304429
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: Allow to specialize smart quotes in documentation translations
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31793>
_______________________________________

From report at bugs.python.org  Sun Oct 15 05:55:25 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Oct 2017 09:55:25 +0000
Subject: [issue31793] Allow to specialize smart quotes in documentation
 translations
In-Reply-To: <1508060988.99.0.213398074469.issue31793@psf.upfronthosting.co.za>
Message-ID: <1508061325.03.0.213398074469.issue31793@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +3980
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31793>
_______________________________________

From report at bugs.python.org  Sun Oct 15 06:08:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 10:08:56 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508062136.23.0.213398074469.issue31792@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I just have installed NumPy. It temporary sets these two environment variables for importing the multiarray numpy extension module, but forgot to remove them if the import is failed.

test_buffer imports numpy.

try:
    with warnings.catch_warnings():
        from numpy import ndarray as numpy_array
except ImportError:
    numpy_array = None

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 06:20:10 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Oct 2017 10:20:10 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508062810.39.0.213398074469.issue31786@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sun Oct 15 07:20:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 11:20:28 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508066428.89.0.213398074469.issue31786@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This particular issue can be fixed by adding the condition (PyFloat_Check(timeout_obj) && PyFloat_AsDouble(timeout_obj) < 0). The problem is only with writing good test for infinity timeout.

This test could be also used for testing issue31334.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sun Oct 15 07:27:52 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Oct 2017 11:27:52 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508066872.22.0.213398074469.issue31792@psf.upfronthosting.co.za>


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

So it is a numpy issue? Which numpy version is it?

----------
versions: +Python 3.8 -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 07:39:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 11:39:04 +0000
Subject: [issue31794] Issues with test.autotest
Message-ID: <1508067544.81.0.213398074469.issue31794@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are issues with running tests by importing test.autotest.

1. test_builtin failed.

0:00:00 load avg: 0.70 [  4/407] test_builtin
test test_builtin failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1735, in test_input_no_stdout_fileno
    lines = self.run_child(child, b"quux\r")
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1680, in run_child
    % (len(lines), child_output))
AssertionError: got 1 lines in pipe but expected 2, child output was:
quux
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1646, in run_child
    child(wpipe)
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1733, in child
    input("prompt")
EOFError: EOF when reading a line


0:00:00 load avg: 0.70 [  5/407/1] test_exceptions -- test_builtin failed
test test_builtin failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1735, in test_input_no_stdout_fileno
    lines = self.run_child(child, b"quux\r")
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1680, in run_child
    % (len(lines), child_output))
AssertionError: got 1 lines in pipe but expected 2, child output was:
quux
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1646, in run_child
    child(wpipe)
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1733, in child
    input("prompt")
EOFError: EOF when reading a line


0:00:01 load avg: 0.70 [  5/407/1] test_exceptions -- test_builtin failed
0:00:01 load avg: 0.70 [  4/407] test_builtin
Warning -- reap_children() reaped child process 4752
0:00:01 load avg: 0.70 [  4/407] test_builtin
0:00:01 load avg: 0.70 [  6/407/1] test_types
test test_builtin failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1735, in test_input_no_stdout_fileno
    lines = self.run_child(child, b"quux\r")
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1680, in run_child
    % (len(lines), child_output))
AssertionError: got 1 lines in pipe but expected 2, child output was:
quux
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1646, in run_child
    child(wpipe)
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1733, in child
    input("prompt")
EOFError: EOF when reading a line


0:00:01 load avg: 0.70 [  5/407/1] test_exceptions -- test_builtin failed
Warning -- reap_children() reaped child process 4755
0:00:01 load avg: 0.70 [  6/407/1] test_types
0:00:01 load avg: 0.70 [  7/407/1] test_unittest
Warning -- reap_children() reaped child process 4758
0:00:01 load avg: 1.12 [  6/407/1] test_types
0:00:01 load avg: 1.12 [  7/407/1] test_unittest
0:00:01 load avg: 1.12 [  7/407/1] test_unittest
test test_builtin failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1735, in test_input_no_stdout_fileno
    lines = self.run_child(child, b"quux\r")
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1680, in run_child
    % (len(lines), child_output))
AssertionError: got 1 lines in pipe but expected 2, child output was:
quux
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1646, in run_child
    child(wpipe)
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1733, in child
    input("prompt")
EOFError: EOF when reading a line


0:00:01 load avg: 1.12 [  5/407/1] test_exceptions -- test_builtin failed
test test_builtin failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1735, in test_input_no_stdout_fileno
    lines = self.run_child(child, b"quux\r")
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1680, in run_child
    % (len(lines), child_output))
AssertionError: got 1 lines in pipe but expected 2, child output was:
quux
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1646, in run_child
    child(wpipe)
  File "/home/serhiy/py/cpython/Lib/test/test_builtin.py", line 1733, in child
    input("prompt")
EOFError: EOF when reading a line


0:00:01 load avg: 1.12 [  5/407/1] test_exceptions -- test_builtin failed
Warning -- reap_children() reaped child process 4761
0:00:01 load avg: 1.12 [  6/407/1] test_types
Warning -- reap_children() reaped child process 4763

Note that warnings and errors are emitted even after reporting that test_builtin failed.


2. Tests are ran multiple times.

0:02:32 load avg: 4.82 [ 77/407/1] test_concurrent_futures
0:02:35 load avg: 4.82 [ 76/407/1] test_complex
0:02:35 load avg: 4.82 [ 77/407/1] test_concurrent_futures
test test_concurrent_futures failed -- multiple errors occurred; run in verbose mode for details
0:03:33 load avg: 1.77 [ 78/407/2] test_configparser -- test_concurrent_futures failed in 1 min 5 sec
test test_concurrent_futures failed -- multiple errors occurred; run in verbose mode for details
0:03:33 load avg: 1.77 [ 78/407/2] test_configparser -- test_concurrent_futures failed in 1 min 5 sec
0:03:34 load avg: 1.77 [ 79/407/2] test_contains
0:03:34 load avg: 1.77 [ 79/407/2] test_contains
0:03:34 load avg: 1.77 [ 80/407/2] test_contextlib
0:03:34 load avg: 1.77 [ 80/407/2] test_contextlib
0:03:34 load avg: 1.77 [ 81/407/2] test_contextlib_async
0:03:34 load avg: 1.77 [ 81/407/2] test_contextlib_async
0:03:34 load avg: 1.77 [ 82/407/2] test_copy
0:03:34 load avg: 1.77 [ 82/407/2] test_copy
0:03:34 load avg: 1.77 [ 83/407/2] test_copyreg
0:03:34 load avg: 1.77 [ 83/407/2] test_copyreg
0:03:34 load avg: 1.77 [ 84/407/2] test_coroutines
test test_concurrent_futures failed -- multiple errors occurred; run in verbose mode for details
0:03:35 load avg: 1.77 [ 84/407/2] test_coroutines
0:03:35 load avg: 1.77 [ 78/407/2] test_configparser -- test_concurrent_futures failed in 1 min 5 sec
0:03:35 load avg: 1.77 [ 85/407/2] test_cprofile
0:03:35 load avg: 1.77 [ 85/407/2] test_cprofile
0:03:35 load avg: 1.77 [ 79/407/2] test_contains
0:03:35 load avg: 1.77 [ 86/407/2] test_crashers
0:03:36 load avg: 1.77 [ 80/407/2] test_contextlib
0:03:36 load avg: 1.77 [ 86/407/2] test_crashers
0:03:36 load avg: 1.77 [ 87/407/2] test_crypt
0:03:36 load avg: 1.77 [ 87/407/2] test_crypt
0:03:36 load avg: 1.77 [ 88/407/2] test_csv
0:03:36 load avg: 1.77 [ 81/407/2] test_contextlib_async
0:03:36 load avg: 1.95 [ 88/407/2] test_csv
0:03:36 load avg: 1.95 [ 82/407/2] test_copy
0:03:36 load avg: 1.95 [ 83/407/2] test_copyreg
0:03:36 load avg: 1.95 [ 84/407/2] test_coroutines
0:03:37 load avg: 1.95 [ 85/407/2] test_cprofile
test test_concurrent_futures failed -- multiple errors occurred; run in verbose mode for details
0:03:37 load avg: 1.95 [ 78/407/2] test_configparser -- test_concurrent_futures failed in 1 min 6 sec


3. test_import changed the environment.

Warning -- files was modified by test_import
  Before: []
  After:  ['@test_4738_tmp.pyc'] 
0:06:18 load avg: 3.72 [178/407/3] test_importlib -- test_import failed (env changed)


4. test_logging failed.

0:07:43 load avg: 3.39 [200/407/3] test_logging
test test_logging failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_logging.py", line 3667, in test_multiprocessing
    self.assertEqual(r.processName, 'MainProcess')
AssertionError: 'ForkServerProcess-192' != 'MainProcess'
- ForkServerProcess-192
+ MainProcess


5. test_mailbox changed the environment.

0:08:10 load avg: 3.13 [205/407/4] test_mailbox
Warning -- files was modified by test_mailbox
  Before: ['@test_4736_tmp.pyc']
  After:  [] 
0:08:11 load avg: 3.36 [206/407/5] test_mailcap -- test_mailbox failed (env changed)


6. test_multiprocessing_fork, test_multiprocessing_forkserver, test_multiprocessing_spawn failed.


7. test_os failed.

test test_os failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_os.py", line 2923, in test_stty_match
    actual = os.get_terminal_size(sys.__stdin__.fileno())
ValueError: I/O operation on closed file

0:11:07 load avg: 2.82 [234/407/9] test_ossaudiodev -- test_os failed


8. The following traceback is output after reporting results.

Exception in thread Thread-162:
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/serhiy/py/cpython/Lib/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/home/serhiy/py/cpython/Lib/concurrent/futures/process.py", line 298, in _queue_management_worker
    shutdown_worker()
  File "/home/serhiy/py/cpython/Lib/concurrent/futures/process.py", line 256, in shutdown_worker
    call_queue.put_nowait(None)
  File "/home/serhiy/py/cpython/Lib/multiprocessing/queues.py", line 129, in put_nowait
    return self.put(obj, False)
  File "/home/serhiy/py/cpython/Lib/multiprocessing/queues.py", line 83, in put
    raise Full
queue.Full


9. After running all tests they are ran again from the start.

----------
components: Tests
messages: 304433
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Issues with test.autotest
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31794>
_______________________________________

From report at bugs.python.org  Sun Oct 15 07:48:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 11:48:49 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508068129.41.0.213398074469.issue31792@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is particularly a NumPy issue (I have opened a bug https://github.com/numpy/numpy/issues/9861). It is exposed because I have installed NumPy with non-debug build of CPython and run the test with debug build of CPython. The test is passes with non-debug build of CPython. I am wondering if we can make a workaround and if we should do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 08:01:32 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Oct 2017 12:01:32 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508068892.3.0.213398074469.issue31792@psf.upfronthosting.co.za>


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

Thanks. If it only occurs when mixing debug/non-debug I don't think we have to do anything about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 08:13:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Oct 2017 12:13:08 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508068892.3.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbQBsr1qVkCs_x_Yt5MnLWwe-sEaa=Af5Wo-T4Or3SjpA@mail.gmail.com>


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

I suggest to always save/restore env vars on numpy import, since we don't
control 3rd party code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 08:26:55 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Oct 2017 12:26:55 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508070415.38.0.213398074469.issue31792@psf.upfronthosting.co.za>


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

That's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 08:44:36 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 12:44:36 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508071476.46.0.213398074469.issue31792@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3981
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 09:13:41 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Oct 2017 13:13:41 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508073221.95.0.213398074469.issue31792@psf.upfronthosting.co.za>


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

I can't figure out how to make the damn button green on GitHub,
so LGTM. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 10:13:38 2017
From: report at bugs.python.org (Pablo)
Date: Sun, 15 Oct 2017 14:13:38 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508076818.72.0.213398074469.issue31786@psf.upfronthosting.co.za>


Pablo <pablogsal at gmail.com> added the comment:

I have added a Pull Request fixing this issue. The current implementation is checking in the syscall if the value for ms before rounding was negative.

To test for this, I call poll.poll in a thread and check that the thread is alive after a join with timeout (so this means it has blocked). Then to clean up, I write to a pipe and therefore it unblocks.

The implementation is available in the PR:

https://github.com/python/cpython/pull/4003

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sun Oct 15 10:32:50 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 14:32:50 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508077970.04.0.213398074469.issue31786@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Pablo. The initial test leaked a thread, now it is much better.

Could you please make the test testing different timeout values: None, -1, -1.0, -0.1, -1e-100?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sun Oct 15 13:49:26 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Oct 2017 17:49:26 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508089766.58.0.213398074469.issue31792@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The issue is fixed on NumPy side (will be included in the next release). Is the workaround on our side still needed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 13:56:15 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Oct 2017 17:56:15 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508090175.32.0.213398074469.issue31792@psf.upfronthosting.co.za>


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

I'd push it so we don't have to worry about similar things in the
future.  The "warnings.catch_warnings()" thing is also a workaround
for some past numpy release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Sun Oct 15 14:06:37 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Sun, 15 Oct 2017 18:06:37 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508090797.8.0.213398074469.issue31788@psf.upfronthosting.co.za>


Aniket Vyas <vyas45 at gmail.com> added the comment:

I can pick this up if it's okay.

----------
nosy: +vyas45

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 14:07:33 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Sun, 15 Oct 2017 18:07:33 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508090853.51.0.213398074469.issue31788@psf.upfronthosting.co.za>


Aniket Vyas <vyas45 at gmail.com> added the comment:

My bad, didn't notice the PR already existing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 15:18:04 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 15 Oct 2017 19:18:04 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508095084.05.0.213398074469.issue31786@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have updated both the test and the implementation to address your feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Sun Oct 15 15:28:33 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 Oct 2017 19:28:33 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508095713.91.0.213398074469.issue31788@psf.upfronthosting.co.za>


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


New changeset 1295e11d397c6138427296d5f9653a9e7dd69062 by Benjamin Peterson (Semen Zhydenko) in branch 'master':
completly -> completely (#3999) (closes bpo-31788)
https://github.com/python/cpython/commit/1295e11d397c6138427296d5f9653a9e7dd69062


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 15:29:49 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Oct 2017 19:29:49 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508095789.74.0.213398074469.issue31788@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3982

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 15:48:54 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 Oct 2017 19:48:54 +0000
Subject: [issue31788] Typo in comments Modules/_ssl.c
In-Reply-To: <1508025359.26.0.213398074469.issue31788@psf.upfronthosting.co.za>
Message-ID: <1508096934.59.0.213398074469.issue31788@psf.upfronthosting.co.za>


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


New changeset cfc604722ff5ad64de96ddeb944661f1e94d8cd0 by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
[3.6] completly -> completely (GH-3999) (closes bpo-31788) (#4008)
https://github.com/python/cpython/commit/cfc604722ff5ad64de96ddeb944661f1e94d8cd0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31788>
_______________________________________

From report at bugs.python.org  Sun Oct 15 16:34:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Oct 2017 20:34:11 +0000
Subject: [issue31791] Ensure that all PyTypeObject fields are set to non-NULL
 defaults
In-Reply-To: <1508048549.34.0.213398074469.issue31791@psf.upfronthosting.co.za>
Message-ID: <1508099651.82.0.213398074469.issue31791@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

For all the reasons Serhiy mentioned, I recommend rejecting this request.  This was an intentional and long-standing design decision. A substantial part of the Python ecosystem depends on it.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31791>
_______________________________________

From report at bugs.python.org  Sun Oct 15 18:45:56 2017
From: report at bugs.python.org (Nitish)
Date: Sun, 15 Oct 2017 22:45:56 +0000
Subject: [issue31795] Slicings documentation doesn't mention Ellipsis
Message-ID: <1508107556.27.0.213398074469.issue31795@psf.upfronthosting.co.za>


New submission from Nitish <nitishchandrachinta at gmail.com>:

Ellipsis object documentation[1] specifies that Ellipsis is mainly used by Slicings. But Slicing's documentation[2] doesn't mention anything about Ellipsis. Consequently - it is not immediately clear from Ellipsis documentation what it's used for.

[1] https://docs.python.org/3/library/stdtypes.html?highlight=ellipsis#the-ellipsis-object

[2] https://docs.python.org/3/reference/expressions.html#slicings

----------
assignee: docs at python
components: Documentation
messages: 304449
nosy: docs at python, nitishch
priority: normal
severity: normal
status: open
title: Slicings documentation doesn't mention Ellipsis
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31795>
_______________________________________

From report at bugs.python.org  Sun Oct 15 21:07:22 2017
From: report at bugs.python.org (fuqianz)
Date: Mon, 16 Oct 2017 01:07:22 +0000
Subject: [issue31796] The mccabe complexity output in module flake8.
Message-ID: <CAHU5Mu03N2Ez5Z9YFxu2ZLT5onkFVo8Ty_dccyDne_pMuhDJjw@mail.gmail.com>


New submission from fuqianz <fqbrighter at gmail.com>:

Dear,
      I have found that if a function name appears more than one time in a
file, the output of McCabe complexity for this function name only appear
once. I think it should output all of them. So, I send this email for
inquiring about this confusing problems.

Thanks,

Sincerely,

fuqianz

----------
messages: 304450
nosy: fqbrighter
priority: normal
severity: normal
status: open
title: The mccabe complexity output in module flake8.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31796>
_______________________________________

From report at bugs.python.org  Sun Oct 15 21:10:01 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Oct 2017 01:10:01 +0000
Subject: [issue31796] The mccabe complexity output in module flake8.
In-Reply-To: <CAHU5Mu03N2Ez5Z9YFxu2ZLT5onkFVo8Ty_dccyDne_pMuhDJjw@mail.gmail.com>
Message-ID: <1508116201.57.0.213398074469.issue31796@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

flake8 is not part of the Python Standard Library.  You might start with its project page here: https://gitlab.com/pycqa/flake8

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31796>
_______________________________________

From report at bugs.python.org  Sun Oct 15 23:24:25 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Oct 2017 03:24:25 +0000
Subject: [issue31795] Slicings documentation doesn't mention Ellipsis
In-Reply-To: <1508107556.27.0.213398074469.issue31795@psf.upfronthosting.co.za>
Message-ID: <1508124265.63.0.213398074469.issue31795@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

In regular Python, the ellipsis isn't used for slicing.  It does have special meaning for numpy.   So, I think the docs may be correct as is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31795>
_______________________________________

From report at bugs.python.org  Mon Oct 16 02:30:31 2017
From: report at bugs.python.org (Nitish)
Date: Mon, 16 Oct 2017 06:30:31 +0000
Subject: [issue31795] Slicings documentation doesn't mention Ellipsis
In-Reply-To: <1508107556.27.0.213398074469.issue31795@psf.upfronthosting.co.za>
Message-ID: <1508135431.4.0.213398074469.issue31795@psf.upfronthosting.co.za>


Nitish <nitishchandrachinta at gmail.com> added the comment:

The problem is that while documentation for other objects like Null object, NotImplemented object make it clear what they are used for, documentation for Ellipsis object only says that it's used in slicings and the slicings documentation doesn't cover Ellipsis.

Can we add an example of its usage in Numpy to the docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31795>
_______________________________________

From report at bugs.python.org  Mon Oct 16 02:49:14 2017
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 Oct 2017 06:49:14 +0000
Subject: [issue31760] Re-definition of _POSIX_C_SOURCE with Fedora 26.
In-Reply-To: <1507734885.66.0.213398074469.issue31760@psf.upfronthosting.co.za>
Message-ID: <1508136554.1.0.213398074469.issue31760@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Looks the same as Issue 31374

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> expat: warning: "_POSIX_C_SOURCE" redefined

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31760>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:08:56 2017
From: report at bugs.python.org (twisteroid ambassador)
Date: Mon, 16 Oct 2017 07:08:56 +0000
Subject: [issue31647] asyncio: StreamWriter write_eof() after close raises
 mysterious AttributeError
In-Reply-To: <1506746563.39.0.213398074469.issue31647@psf.upfronthosting.co.za>
Message-ID: <1508137736.43.0.213398074469.issue31647@psf.upfronthosting.co.za>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
nosy: +giampaolo.rodola, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31647>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:29:33 2017
From: report at bugs.python.org (Nitish)
Date: Mon, 16 Oct 2017 07:29:33 +0000
Subject: [issue31774] tarfile.open ignores custom bufsize value when creating
 a new archive
In-Reply-To: <1507817839.86.0.213398074469.issue31774@psf.upfronthosting.co.za>
Message-ID: <1508138973.22.0.213398074469.issue31774@psf.upfronthosting.co.za>


Change by Nitish <nitishchandrachinta at gmail.com>:


----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31774>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:38:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Oct 2017 07:38:17 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508139497.06.0.213398074469.issue31792@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 676db4bbf2e7c18dc7c35add17dd3bbdc2d3eeb3 by Serhiy Storchaka in branch 'master':
bpo-31792: Restore os.environ in test_buffer when import numpy. (#4007)
https://github.com/python/cpython/commit/676db4bbf2e7c18dc7c35add17dd3bbdc2d3eeb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:38:26 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Oct 2017 07:38:26 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508139506.31.0.213398074469.issue31792@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3983

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:42:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 07:42:38 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508139758.02.0.213398074469.issue31786@psf.upfronthosting.co.za>


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

Ok, so it seems like we need 3 rounding modes:

* _PyTime_ROUND_FLOOR: read a clock, like datetime.datetime.now(). We need to round nanoseconds since datetime.datetime only supports 1 us resolution

* _PyTime_ROUND_HALF_EVEN: "round from a Python float" like round(float), used by datetime.datetime.fromtimestamp()

* _PyTime_ROUND_UP: round timeouts, socket.settimeout(), lock.acquire(timeout), poll(timeout), etc.

_PyTime_ROUND_UP and _PyTime_ROUND_CEILING are the same for positive numbers, but using _PyTime_ROUND_CEILING causes this bug: values in ]-0.5; 0.0[ are rounding to zero which gives the wrong behaviour. It seems like _PyTime_ROUND_CEILING is not needed in Python currently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:49:20 2017
From: report at bugs.python.org (Nitish)
Date: Mon, 16 Oct 2017 07:49:20 +0000
Subject: [issue31774] tarfile.open ignores custom bufsize value when creating
 a new archive
In-Reply-To: <1507817839.86.0.213398074469.issue31774@psf.upfronthosting.co.za>
Message-ID: <1508140160.24.0.213398074469.issue31774@psf.upfronthosting.co.za>


Nitish <nitishchandrachinta at gmail.com> added the comment:

Seems like bufsize is used only in streaming modes. Even in the documentation bufsize is described only in the context of streaming modes. 

Even TarFile constructor doesn't take bufsize as an argument. Why is it so?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31774>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:50:32 2017
From: report at bugs.python.org (Nitish)
Date: Mon, 16 Oct 2017 07:50:32 +0000
Subject: [issue31774] tarfile.open ignores custom bufsize value when creating
 a new archive
In-Reply-To: <1507817839.86.0.213398074469.issue31774@psf.upfronthosting.co.za>
Message-ID: <1508140232.13.0.213398074469.issue31774@psf.upfronthosting.co.za>


Nitish <nitishchandrachinta at gmail.com> added the comment:

Sorry. My bad. There *is* an argument 'copybufsize' in TarFile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31774>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:51:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 07:51:58 +0000
Subject: [issue31647] asyncio: StreamWriter write_eof() after close raises
 mysterious AttributeError
In-Reply-To: <1506746563.39.0.213398074469.issue31647@psf.upfronthosting.co.za>
Message-ID: <1508140318.45.0.213398074469.issue31647@psf.upfronthosting.co.za>


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

(Sorry, I don't work on asyncio anymore.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31647>
_______________________________________

From report at bugs.python.org  Mon Oct 16 03:52:18 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 07:52:18 +0000
Subject: [issue31647] asyncio: StreamWriter write_eof() after close raises
 mysterious AttributeError
In-Reply-To: <1506746563.39.0.213398074469.issue31647@psf.upfronthosting.co.za>
Message-ID: <1508140338.72.0.213398074469.issue31647@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31647>
_______________________________________

From report at bugs.python.org  Mon Oct 16 04:21:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Oct 2017 08:21:35 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508142095.92.0.213398074469.issue31792@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 06949585d292d1a9dbf2d0d0fa8fc8fe1dee3ccf by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31792: Restore os.environ in test_buffer when import numpy. (GH-4007) (#4009)
https://github.com/python/cpython/commit/06949585d292d1a9dbf2d0d0fa8fc8fe1dee3ccf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Mon Oct 16 04:22:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Oct 2017 08:22:33 +0000
Subject: [issue31792] test_buffer altered the execution environment
In-Reply-To: <1508060157.98.0.213398074469.issue31792@psf.upfronthosting.co.za>
Message-ID: <1508142153.44.0.213398074469.issue31792@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Victor and Stefan for your review.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31792>
_______________________________________

From report at bugs.python.org  Mon Oct 16 04:24:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Oct 2017 08:24:25 +0000
Subject: [issue31776] Missing "raise from None" in
 /Lib/xml/etree/ElementPath.py
In-Reply-To: <1507841968.12.0.213398074469.issue31776@psf.upfronthosting.co.za>
Message-ID: <1508142265.13.0.213398074469.issue31776@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0df19055c92a0b0728659807978e4ca4d6c8e1bc by Serhiy Storchaka (Pablo Galindo) in branch 'master':
bpo-31776: Missing "raise from None" in Lib/xml/etree/ElementPath.py (#3978)
https://github.com/python/cpython/commit/0df19055c92a0b0728659807978e4ca4d6c8e1bc


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31776>
_______________________________________

From report at bugs.python.org  Mon Oct 16 04:25:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Oct 2017 08:25:46 +0000
Subject: [issue31776] Missing "raise from None" in
 /Lib/xml/etree/ElementPath.py
In-Reply-To: <1507841968.12.0.213398074469.issue31776@psf.upfronthosting.co.za>
Message-ID: <1508142346.33.0.213398074469.issue31776@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: behavior -> enhancement
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31776>
_______________________________________

From report at bugs.python.org  Mon Oct 16 04:28:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 08:28:51 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508142531.58.0.213398074469.issue31786@psf.upfronthosting.co.za>


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

> It seems like _PyTime_ROUND_CEILING is not needed in Python currently.

Oops, my pending PR 3983 uses _PyTime_ROUND_CEILING :-) Please keep it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Mon Oct 16 05:50:57 2017
From: report at bugs.python.org (Devin Bayer)
Date: Mon, 16 Oct 2017 09:50:57 +0000
Subject: [issue31772] SourceLoader uses stale bytecode in case of equal mtime
 seconds
In-Reply-To: <1507815780.34.0.213398074469.issue31772@psf.upfronthosting.co.za>
Message-ID: <1508147457.36.0.213398074469.issue31772@psf.upfronthosting.co.za>


Devin Bayer <dev at doubly.so> added the comment:

That seems like it makes the most sense, though I would suggest a higher-level test, because caching of bytecode is an implementation detail. So, while mocking time.time to be constant:

1. write dummy module with x=1
2. import dummy
3. overwrite dummy module with x=2
4. reload(dummy)
5. assert dummy.x == 2

BTW Brett, I didn't think it was personal; that would be odd considering you don't know me. But from a new contributor's perspective it didn't look like you are taking bugs seriously. If you had pointed out that you will reopen it if I made a good case, that would be been more clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31772>
_______________________________________

From report at bugs.python.org  Mon Oct 16 06:14:43 2017
From: report at bugs.python.org (Francesco Mantovani)
Date: Mon, 16 Oct 2017 10:14:43 +0000
Subject: [issue31797] Python 3.6.3: JSON loop fails using elif
Message-ID: <1508148883.41.0.213398074469.issue31797@psf.upfronthosting.co.za>


New submission from Francesco Mantovani <francesco84mantovani at gmail.com>:

I attach here a file with 3 different way to parse Google Places API.

Please put your Google API key token into the variable [PutHereYourGoogleAPIKey] to make the script work.

The script contains 3 loops:
- the first loop works and that's how I fixed the problem 
- the second loop fail because of the `elif`
- the third loop works because all `elif` were removed

----------
components: Interpreter Core
files: Test_log_bug.py
messages: 304465
nosy: Francesco Mantovani
priority: normal
severity: normal
status: open
title: Python 3.6.3: JSON loop fails using elif
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47222/Test_log_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31797>
_______________________________________

From report at bugs.python.org  Mon Oct 16 06:55:47 2017
From: report at bugs.python.org (Alexander McFarlane)
Date: Mon, 16 Oct 2017 10:55:47 +0000
Subject: [issue31798] abs__file__ in "Lib/site.py"
Message-ID: <1508151347.82.0.213398074469.issue31798@psf.upfronthosting.co.za>


Change by Alexander McFarlane <alex.mcfarlane.uk at gmail.com>:


----------
nosy: Alexander McFarlane
priority: normal
severity: normal
status: open
title: abs__file__ in "Lib/site.py"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31798>
_______________________________________

From report at bugs.python.org  Mon Oct 16 07:00:16 2017
From: report at bugs.python.org (Alexander McFarlane)
Date: Mon, 16 Oct 2017 11:00:16 +0000
Subject: [issue31798] "abs__file__" in "Lib/site.py" fails for modules where
 "__file__" cannot be assigned a new value
Message-ID: <1508151616.4.0.213398074469.issue31798@psf.upfronthosting.co.za>


New submission from Alexander McFarlane <alex.mcfarlane.uk at gmail.com>:

The pythonnet module clr causes a TypeError when `abs__file__` attempts to run the following line:

`m.__file__ = os.path.abspath(m.__file__)`

Reproduction:

```
import clr
cls.__file__ = 'example'
```

----------
components: +Library (Lib)
title: abs__file__ in "Lib/site.py" -> "abs__file__" in "Lib/site.py" fails for modules where "__file__" cannot be assigned a new value
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31798>
_______________________________________

From report at bugs.python.org  Mon Oct 16 07:00:34 2017
From: report at bugs.python.org (Alexander McFarlane)
Date: Mon, 16 Oct 2017 11:00:34 +0000
Subject: [issue31798] "abs__file__" in "Lib/site.py" fails for modules where
 "__file__" cannot be assigned a new value
In-Reply-To: <1508151616.4.0.213398074469.issue31798@psf.upfronthosting.co.za>
Message-ID: <1508151634.13.0.213398074469.issue31798@psf.upfronthosting.co.za>


Change by Alexander McFarlane <alex.mcfarlane.uk at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31798>
_______________________________________

From report at bugs.python.org  Mon Oct 16 07:02:46 2017
From: report at bugs.python.org (Alexander McFarlane)
Date: Mon, 16 Oct 2017 11:02:46 +0000
Subject: [issue31798] `site.abs__file__` fails for modules where `__file__`
 cannot be modified
In-Reply-To: <1508151616.4.0.213398074469.issue31798@psf.upfronthosting.co.za>
Message-ID: <1508151766.6.0.213398074469.issue31798@psf.upfronthosting.co.za>


Change by Alexander McFarlane <alex.mcfarlane.uk at gmail.com>:


----------
title: "abs__file__" in "Lib/site.py" fails for modules where "__file__" cannot be assigned a new value -> `site.abs__file__` fails for modules where `__file__` cannot be modified

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31798>
_______________________________________

From report at bugs.python.org  Mon Oct 16 08:06:43 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Oct 2017 12:06:43 +0000
Subject: [issue31795] Slicings documentation doesn't mention Ellipsis
In-Reply-To: <1508107556.27.0.213398074469.issue31795@psf.upfronthosting.co.za>
Message-ID: <1508155603.85.0.213398074469.issue31795@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Can we add an example of its usage in Numpy to the docs?

I don't think we should.   In CPython, the ellipsis has no interesting semantics.  It is something that third-party modules can use however they wish.  It doesn't make sense for CPython docs to cover their usage.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31795>
_______________________________________

From report at bugs.python.org  Mon Oct 16 08:21:01 2017
From: report at bugs.python.org (Matthew Rocklin)
Date: Mon, 16 Oct 2017 12:21:01 +0000
Subject: [issue31308] forkserver process isn't re-launched if it died
In-Reply-To: <1504103235.79.0.43802074293.issue31308@psf.upfronthosting.co.za>
Message-ID: <1508156461.69.0.213398074469.issue31308@psf.upfronthosting.co.za>


Matthew Rocklin <mrocklin at gmail.com> added the comment:

>From a user's perspective I would definitely appreciate forkserver being protected from SIGINT.  This bug affects me in practice.  If the forkserver goes down I personally have no objection to it restarting automatically, though I appreciate that I have a narrow view of this topic.

Davin, at your last comment it seemed like you had reservations about this going in.  Did Antoine's recent comments resolve these concerns or no?  Do you have any suggestions on what might be done to protect users from SIGINT crashing the forkserver?

----------
nosy: +Matthew Rocklin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31308>
_______________________________________

From report at bugs.python.org  Mon Oct 16 08:30:43 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 16 Oct 2017 12:30:43 +0000
Subject: [issue31797] Python 3.6.3: JSON loop fails using elif
In-Reply-To: <1508148883.41.0.213398074469.issue31797@psf.upfronthosting.co.za>
Message-ID: <1508157043.88.0.213398074469.issue31797@psf.upfronthosting.co.za>


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

Hi, Francesco.

This isn't the appropriate place to ask for help with your script.

I suggest trying the python-list mailing list.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31797>
_______________________________________

From report at bugs.python.org  Mon Oct 16 08:33:03 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 16 Oct 2017 12:33:03 +0000
Subject: [issue31797] Python 3.6.3: JSON loop fails using elif
In-Reply-To: <1508148883.41.0.213398074469.issue31797@psf.upfronthosting.co.za>
Message-ID: <1508157183.07.0.213398074469.issue31797@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

What are you claiming is the bug? I don't understand what you think the problem is.

Don't dump a large script in our laps and expect us to get a Google API key to run it. Forget that, it isn't going to happen. Simplify your code to make the smallest, simplest demonstration you can.

Please read: http://sscce.org/

Then tell us:

- what you expect to happen
- what actually happens
- show any output you get
- including any exception.


To start with, there's no need to query five fields, if one field is enough. Make your code as simple as you can. Don't leave "dead code" commented out, delete it.

----------
nosy: +steven.daprano -eric.smith
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31797>
_______________________________________

From report at bugs.python.org  Mon Oct 16 08:35:50 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 16 Oct 2017 12:35:50 +0000
Subject: [issue31797] Python 3.6.3: JSON loop fails using elif
In-Reply-To: <1508148883.41.0.213398074469.issue31797@psf.upfronthosting.co.za>
Message-ID: <1508157350.61.0.213398074469.issue31797@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oops, accidentally messed up the status. Fixing now.

Francesco, if you simplify your code and come back with a detailed description of what you think the bug is, then we will investigate.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31797>
_______________________________________

From report at bugs.python.org  Mon Oct 16 09:00:43 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Oct 2017 13:00:43 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508158843.14.0.213398074469.issue31334@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Shouldn't epoll_poll() be fixed too? Only -1 is documented as an infinity timeout in epoll_wait (2).

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Mon Oct 16 09:04:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 13:04:57 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508159097.25.0.213398074469.issue31334@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Mon Oct 16 09:19:50 2017
From: report at bugs.python.org (Riccardo Coccioli)
Date: Mon, 16 Oct 2017 13:19:50 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508159990.36.0.213398074469.issue31334@psf.upfronthosting.co.za>


Riccardo Coccioli <rcoccioli at gmail.com> added the comment:

Although it's documented as -1 in Linux man page [1], from my quick tests I was not able to get any error with negative values different from -1 and it seems to wait indefinitely as expected. Looking also at its implementation in [2], it doesn't seem to differentiate between negative values. It could be argued that is implementation dependent at the moment and the behaviour might change in the future.
But, on a related note, the Python documentation doesn't say much either as what are acceptable values for the timeout parameter, see [3].

So at the moment there isn't any discrepancy between the Python documentation and the current behaviour IMHO, but I'm happy to open a separate task and send a PR if you think this should be improved/fixed too.

[1] http://man7.org/linux/man-pages/man2/epoll_wait.2.html
[2] http://elixir.free-electrons.com/linux/latest/source/fs/eventpoll.c#L1754
[3] https://docs.python.org/3.7/library/select.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Mon Oct 16 09:27:06 2017
From: report at bugs.python.org (Riccardo Coccioli)
Date: Mon, 16 Oct 2017 13:27:06 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508160426.32.0.213398074469.issue31786@psf.upfronthosting.co.za>


Change by Riccardo Coccioli <rcoccioli at gmail.com>:


----------
nosy: +Riccardo Coccioli

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Mon Oct 16 10:16:27 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 Oct 2017 14:16:27 +0000
Subject: [issue31799] Improve __spec__ discoverability
Message-ID: <1508163387.44.0.213398074469.issue31799@psf.upfronthosting.co.za>


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

__spec__ is defined in PEP 451.  If you search for "__spec__" in the docs, you get a number of hits.

https://docs.python.org/3/search.html?q=__spec__&check_keywords=yes&area=default

Click on the first link:

https://docs.python.org/3/reference/import.html?highlight=__spec__#__spec__

but that still leaves you scratching your head as to what exactly is in __spec__.  If you happen to scroll up a little bit though, you end up here:

https://docs.python.org/3/reference/import.html?highlight=__spec__#module-spec

and then if you follow the link to ModuleSpec, you finally get to here:

https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec

and *that's* where the contents of __spec__ are defined.  Not very discoverable.

I propose just a couple of small documentation fixes to add "__spec__" in both of those locations so that a search lands you in a useful place.

----------
assignee: barry
components: Documentation
messages: 304474
nosy: barry
priority: normal
severity: normal
status: open
title: Improve __spec__ discoverability
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31799>
_______________________________________

From report at bugs.python.org  Mon Oct 16 10:46:58 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 Oct 2017 14:46:58 +0000
Subject: [issue31799] Improve __spec__ discoverability
In-Reply-To: <1508163387.44.0.213398074469.issue31799@psf.upfronthosting.co.za>
Message-ID: <1508165218.32.0.213398074469.issue31799@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3984
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31799>
_______________________________________

From report at bugs.python.org  Mon Oct 16 10:46:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 14:46:59 +0000
Subject: [issue31784] Implementation of the PEP 564: Add time.time_ns()
In-Reply-To: <1507930455.75.0.213398074469.issue31784@psf.upfronthosting.co.za>
Message-ID: <1508165219.83.0.213398074469.issue31784@psf.upfronthosting.co.za>


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


----------
title: Add time.time_ns(): get time with nanosecond resolution -> Implementation of the PEP 564: Add time.time_ns()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31784>
_______________________________________

From report at bugs.python.org  Mon Oct 16 10:47:48 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 14:47:48 +0000
Subject: [issue31784] Implementation of the PEP 564: Add time.time_ns()
In-Reply-To: <1507930455.75.0.213398074469.issue31784@psf.upfronthosting.co.za>
Message-ID: <1508165268.88.0.213398074469.issue31784@psf.upfronthosting.co.za>


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

> For the full rationale, see my thread on python-ideas: (...)

I just created the PEP 564: "Add new time functions with nanosecond resolution".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31784>
_______________________________________

From report at bugs.python.org  Mon Oct 16 11:36:01 2017
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 16 Oct 2017 15:36:01 +0000
Subject: [issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5,
 reliable in 3.6)
In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za>
Message-ID: <1508168161.11.0.213398074469.issue28700@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I have this failure on my machine too (Ubuntu 17.04, kernel 4.10.0-37-generic).

Installing `libgdbm-dev` and running configure with `--with-dbmliborder=gdbm:bdb` didn't help.

----------
nosy: +facundobatista

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28700>
_______________________________________

From report at bugs.python.org  Mon Oct 16 11:44:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Oct 2017 15:44:38 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1508168678.24.0.213398074469.issue31773@psf.upfronthosting.co.za>


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


New changeset bdaeb7d237462a629e6c85001317faa85f94a0c6 by Victor Stinner in branch 'master':
bpo-31773: _PyTime_GetPerfCounter() uses _PyTime_t (GH-3983)
https://github.com/python/cpython/commit/bdaeb7d237462a629e6c85001317faa85f94a0c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Mon Oct 16 13:21:03 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Mon, 16 Oct 2017 17:21:03 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508174463.73.0.213398074469.issue31754@psf.upfronthosting.co.za>


Change by Aniket Vyas <vyas45 at gmail.com>:


----------
pull_requests: +3985
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Mon Oct 16 13:53:58 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 16 Oct 2017 17:53:58 +0000
Subject: [issue31738] Lib/site.py: method `abs_paths` is not documented
In-Reply-To: <1507581303.97.0.213398074469.issue31738@psf.upfronthosting.co.za>
Message-ID: <1508176438.56.0.213398074469.issue31738@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for wanting to help!  This function is not meant to be public, which explains why it?s not documented.  Please see the devguide and the core-mentorship mailing list to find ways to contribute!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31738>
_______________________________________

From report at bugs.python.org  Mon Oct 16 14:15:20 2017
From: report at bugs.python.org (Aniket Vyas)
Date: Mon, 16 Oct 2017 18:15:20 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508177720.75.0.213398074469.issue31754@psf.upfronthosting.co.za>


Change by Aniket Vyas <vyas45 at gmail.com>:


----------
pull_requests: +3986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Mon Oct 16 14:23:46 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Oct 2017 18:23:46 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508178226.56.0.213398074469.issue31754@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 50cef52372381a9e2f3d760497d8db76254cffef by Berker Peksag (vyas45) in branch '2.7':
[2.7] bpo-31754: Fix type of 'itemsize' in PyBuffer_FillContiguousStrides (GH-3993)
https://github.com/python/cpython/commit/50cef52372381a9e2f3d760497d8db76254cffef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Mon Oct 16 14:26:06 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Oct 2017 18:26:06 +0000
Subject: [issue31754] Documented type of parameter 'itemsize' to
 PyBuffer_FillContiguousStrides is incorrect.
In-Reply-To: <1507681127.43.0.213398074469.issue31754@psf.upfronthosting.co.za>
Message-ID: <1508178366.13.0.213398074469.issue31754@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the report, Robert and thank you for the patches, Aniket.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31754>
_______________________________________

From report at bugs.python.org  Mon Oct 16 15:48:12 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 Oct 2017 19:48:12 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1508183292.98.0.213398074469.issue31558@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Based on Inadasan's, Antoine's, Neil's, and Barry's review, I'm merging the change to 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Mon Oct 16 15:49:47 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 Oct 2017 19:49:47 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1508183387.11.0.213398074469.issue31558@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset c75edabbb65ca2bb29e51f8d1eb2c780e5890982 by ?ukasz Langa (brainfvck) in branch 'master':
bpo-31558: Add gc.freeze() (#3705)
https://github.com/python/cpython/commit/c75edabbb65ca2bb29e51f8d1eb2c780e5890982


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Mon Oct 16 15:50:28 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 Oct 2017 19:50:28 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1508183428.59.0.213398074469.issue31558@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Mon Oct 16 17:28:47 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 Oct 2017 21:28:47 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1508189327.07.0.213398074469.issue31558@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
pull_requests: +3987

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Mon Oct 16 17:38:31 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 Oct 2017 21:38:31 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1508189911.86.0.213398074469.issue25711@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Mon Oct 16 17:39:10 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 16 Oct 2017 21:39:10 +0000
Subject: [issue31558] gc.freeze() - an API to mark objects as uncollectable
In-Reply-To: <1506126089.65.0.135296831106.issue31558@psf.upfronthosting.co.za>
Message-ID: <1508189950.78.0.213398074469.issue31558@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset c30b55b96c0967e3a8b3b86f25eb012a97f360a5 by ?ukasz Langa in branch 'master':
bpo-31558: Update NEWS and ACKS (#4013)
https://github.com/python/cpython/commit/c30b55b96c0967e3a8b3b86f25eb012a97f360a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31558>
_______________________________________

From report at bugs.python.org  Mon Oct 16 17:42:31 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 Oct 2017 21:42:31 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1508190151.57.0.213398074469.issue25711@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I've landed here after chatting with @brett.cannon.  I have a use case for this (making pex startup faster by bypassing pkg_resources) but I need to hack around the limitation of dlopen'ing .so's from zips.  Our idea was to have a zipimport subclass which doesn't return None from `importlib.util.find_spec()` when it finds a .so, but instead dumps that into some safe directory, and then arranges for a loader that knows how to load that.  It sure would be handy for this to be a zipimporter subclass. :)

I think Serhiy's patch predates the move to GitHub, so it's not a branch/PR.  I guess the next step would be to branchify the patch and then continue discussion over there.  Depending on my availability, I might do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Mon Oct 16 18:28:29 2017
From: report at bugs.python.org (Zane Bitter)
Date: Mon, 16 Oct 2017 22:28:29 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508192909.6.0.213398074469.issue28603@psf.upfronthosting.co.za>


Change by Zane Bitter <zaneb at fedoraproject.org>:


----------
pull_requests: +3988

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Mon Oct 16 18:44:28 2017
From: report at bugs.python.org (Zane Bitter)
Date: Mon, 16 Oct 2017 22:44:28 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508193868.87.0.213398074469.issue28603@psf.upfronthosting.co.za>


Zane Bitter <zaneb at fedoraproject.org> added the comment:

I also encountered this issue, and I'd like to further note that it is extraordinarily difficult to debug without access to stderr. If your logging facility uses the traceback module then it will be unable to record both the original (unhashable) exception, and the TypeError that it triggers (since the original exception is its __context__). The effect is that execution of a thread appears to simply stop without rhyme or reason (in fact it is still executing, but that fact is not apparent from the logs). I'm attaching a short reproducer that demonstrates this effect.

I believe the trade-offs inherent in the attached patches (either stopping the chain at an unhashable exception, or using a less-efficient data structure) can be avoided by comparing for identity rather than equality. The purpose of the check is to avoid an infinite loop; whether the objects compare as equal is something that is up to the author of the class, and has no relevance here except insofar as that objects ought to compare equal to themselves.

I submitted a pull request (#4014) with an implementation of that.

----------
nosy: +zaneb
Added file: https://bugs.python.org/file47223/hashex.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Mon Oct 16 18:51:49 2017
From: report at bugs.python.org (Mario Corchero)
Date: Mon, 16 Oct 2017 22:51:49 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
Message-ID: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Currently, datetime.strptime does not support parsing utc offsets that include a colon. "+0000" is parsed without issues whilst it fails with "+00:00".

"+NN:NN" is not only ISO8601 valid but also the way the offset is presented to the user when using .isoformat on a datetime with a timezone/offset.

This lead to the users needing to go to external libraries like dateutil or iso8601 just to be able to parse the datetime encoded in strings that "datetime" produces.

Even if a long-term goal would be to provide a way to parse any isoformatted string this issue just aims to address the problem that the %z parsing presents. This already unblocks users from parsing datetime object serialized with isoformat.

With this change, the following will just work:

>>> import datetime as dt
>>> iso_fmt = '%Y-%m-%dT%H:%M:%S%z'
>>> d = dt.datetime.strptime('2004-01-01T10:10:10+05:00', iso_fmt)

*'2004-01-01T10:10:10+05:00' is a sample string generated via datetime.isoformat()

Other options like having a new %:z was proposed but having just %z seems much simpler for the user.



Note: There has been already conversations about adding support on datetime to parse any ISO-formatted string. This is a more simplistic approach. We might be able to get to that situation after this patch, but this aims just to unblock us.

Related:
http://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf
https://mail.python.org/pipermail/python-ideas/2014-March/027018.html
https://bugs.python.org/issue15873

----------
components: Library (Lib)
messages: 304486
nosy: mariocj89
priority: normal
severity: normal
status: open
title: datetime.strptime: Support for parsing offsets with a colon
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Mon Oct 16 18:54:18 2017
From: report at bugs.python.org (Mario Corchero)
Date: Mon, 16 Oct 2017 22:54:18 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508194458.88.0.213398074469.issue31800@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
keywords: +patch
pull_requests: +3989
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Mon Oct 16 20:21:55 2017
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Oct 2017 00:21:55 +0000
Subject: [issue31801] vars() manipulation encounters problems with Enum
Message-ID: <1508199715.37.0.213398074469.issue31801@psf.upfronthosting.co.za>


New submission from Ethan Furman <ethan at stoneleaf.us>:

The following code should work (from https://stackoverflow.com/a/46780742/208880):


    class BaudRate(Enum):

        cls = vars()
        regexp = r"(?:^|,)B(?P<rate>\d+)"
        rates = sorted(map(int, re.findall(regexp, ",".join(dir(termios)))))
        for value in rates:
            cls['B%d' % value] = value

        @classmethod
        def valid_rate(cls, value):
            return (any(value == item.value for item in cls))


This doesn't work because EnumMeta does not allow names to be reassigned nor deleted.  aenum gets around this by allowing an _ignore_ attribute which contains the names that should not be tracked (and, in fact, those names are removed from the final class).

Unless a better idea is put forward, I will add _ignore_ support to Enum.

----------
assignee: ethan.furman
messages: 304487
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: test needed
status: open
title: vars() manipulation encounters problems with Enum
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31801>
_______________________________________

From report at bugs.python.org  Mon Oct 16 21:37:07 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 17 Oct 2017 01:37:07 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508204227.26.0.213398074469.issue31800@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Mon Oct 16 22:01:33 2017
From: report at bugs.python.org (Tim Peters)
Date: Tue, 17 Oct 2017 02:01:33 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1508205693.07.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

On 16 Oct 2017, exactly the same test failures were reported on python-dev:

https://mail.python.org/pipermail/python-dev/2017-October/149880.html

>From the test output posted there:

"""
== CPython 3.6.3 (default, Oct 16 2017, 14:42:21) [GCC 4.7.2]
== Linux-3.2.0-4-686-pae-i686-with-debian-7.11 little-endian
"""

And I just noticed that in issue27953 exactly the same bad tan result() was reported (on "OS X Tiger").

It's hard to believe that three different systems (four, if I include wxMaxima) deliver exactly the same bad result by accident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Tue Oct 17 00:12:30 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Oct 2017 04:12:30 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508213550.79.0.213398074469.issue31800@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

FWIW it looks like ?strptime? in glibc, and Open and Free BSD support parsing this and even more formats (RFC 822 and RFC 3339; includes ?Z?, U.S. time zones, ?HH). Also, there is Issue 24954 for adding ?%:z? like Gnu ?date?.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Tue Oct 17 00:15:00 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Oct 2017 04:15:00 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508213700.53.0.213398074469.issue31800@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Sorry, I meant Net BSD not Free BSD

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Tue Oct 17 03:47:12 2017
From: report at bugs.python.org (Alex Dzyoba)
Date: Tue, 17 Oct 2017 07:47:12 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1508226432.91.0.213398074469.issue14465@psf.upfronthosting.co.za>


Change by Alex Dzyoba <alex.dzyoba at gmail.com>:


----------
pull_requests: +3990
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Tue Oct 17 04:35:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 08:35:25 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1508229325.26.0.213398074469.issue31733@psf.upfronthosting.co.za>


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


New changeset 3c082a7fdb472f02bcac7a7f8fe1e3a34a11b70b by Victor Stinner in branch '2.7':
bpo-31733: Add PYTHONSHOWREFCOUNT env var (GH-3932)
https://github.com/python/cpython/commit/3c082a7fdb472f02bcac7a7f8fe1e3a34a11b70b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Tue Oct 17 05:25:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 09:25:28 +0000
Subject: [issue19527] Test failures with COUNT_ALLOCS
In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za>
Message-ID: <1508232328.0.0.213398074469.issue19527@psf.upfronthosting.co.za>


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


New changeset 7b4ba62e388474e811268322b47f80d464933541 by Victor Stinner in branch '2.7':
[2.7] bpo-31692: Add PYTHONSHOWALLOCCOUNT env var (GH-3927)
https://github.com/python/cpython/commit/7b4ba62e388474e811268322b47f80d464933541


----------

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

From report at bugs.python.org  Tue Oct 17 05:25:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 09:25:28 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508232328.26.0.912454111764.issue31692@psf.upfronthosting.co.za>


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


New changeset 7b4ba62e388474e811268322b47f80d464933541 by Victor Stinner in branch '2.7':
[2.7] bpo-31692: Add PYTHONSHOWALLOCCOUNT env var (GH-3927)
https://github.com/python/cpython/commit/7b4ba62e388474e811268322b47f80d464933541


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 05:45:21 2017
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 17 Oct 2017 09:45:21 +0000
Subject: [issue31802] 'import posixpath' fails if 'os.path' has not be
 imported already.
Message-ID: <1508233521.36.0.213398074469.issue31802@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

$ python3.7 -S
>>> import posixpath
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "--/Lib/posixpath.py", line 13, in <module>
    import os
  File "--/Lib/os.py", line 92, in <module>
    from os.path import (curdir, pardir, sep, pathsep, defpath, extsep, altsep,
ImportError: cannot import name 'curdir' from 'posixpath' (--/Lib/posixpath.py)

Whether this counts as a bug or not is debatable. It could be argued that you shouldn't be importing 'posixpath' directly, in which case it ought to be called '_posixpath', but I guess it is too late to be changing the name.

----------
messages: 304494
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: 'import posixpath' fails if 'os.path' has not be imported already.
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 06:03:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 10:03:02 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508234582.11.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

Python 2.7.15 will require to compile Python with COUNT_ALLOCS defined *and* to set the PYTHONSHOWALLOCCOUNT environment variable (ex: PYTHONSHOWALLOCCOUNT=1) to dump allocation counts. Moreover, counts are now dumped into stderr, instead of stdout.

Python 2.7 test suite now pass when Python is compiled with COUNT_ALLOCS.

Python 2.7 test suite doens't pass with PYTHONSHOWALLOCCOUNT set. I don't think that it's worth it to fix this case.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 06:03:43 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 10:03:43 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1508234623.37.0.213398074469.issue31733@psf.upfronthosting.co.za>


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

Python 2.7.15 now requires to set PYTHONSHOWREFCOUNT env var to dump "[xxx refs]".

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Tue Oct 17 06:17:44 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 10:17:44 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508235464.49.0.213398074469.issue31692@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Isn't worth to document these changes in What's New?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 06:46:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 10:46:12 +0000
Subject: [issue31802] 'import posixpath' fails if 'os.path' has not be
 imported already.
In-Reply-To: <1508233521.36.0.213398074469.issue31802@psf.upfronthosting.co.za>
Message-ID: <1508237172.51.0.213398074469.issue31802@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
components: +Library (Lib)
nosy: +serhiy.storchaka
type: crash -> behavior
versions: +Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 07:35:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 11:35:15 +0000
Subject: [issue30541] Add restricted mocks to the python unittest mocking
 framework
In-Reply-To: <1496348216.16.0.694231026308.issue30541@psf.upfronthosting.co.za>
Message-ID: <1508240115.04.0.213398074469.issue30541@psf.upfronthosting.co.za>


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


New changeset 552be9d7e64f91b8e4ba5b29cd5dcc442d56f92c by Victor Stinner (Mario Corchero) in branch 'master':
bpo-30541: Add new method to seal mocks (GH61923)
https://github.com/python/cpython/commit/552be9d7e64f91b8e4ba5b29cd5dcc442d56f92c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30541>
_______________________________________

From report at bugs.python.org  Tue Oct 17 07:36:43 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 11:36:43 +0000
Subject: [issue30541] Add restricted mocks to the python unittest mocking
 framework
In-Reply-To: <1496348216.16.0.694231026308.issue30541@psf.upfronthosting.co.za>
Message-ID: <1508240203.72.0.213398074469.issue30541@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30541>
_______________________________________

From report at bugs.python.org  Tue Oct 17 07:40:48 2017
From: report at bugs.python.org (Florian Weimer)
Date: Tue, 17 Oct 2017 11:40:48 +0000
Subject: [issue30013] Compiler warning in Modules/posixmodule.c
In-Reply-To: <1491559004.62.0.18619105038.issue30013@psf.upfronthosting.co.za>
Message-ID: <1508240448.79.0.213398074469.issue30013@psf.upfronthosting.co.za>


Change by Florian Weimer <fweimer at redhat.com>:


----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30013>
_______________________________________

From report at bugs.python.org  Tue Oct 17 07:54:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 11:54:28 +0000
Subject: [issue31802] 'import posixpath' fails if 'os.path' has not be
 imported already.
In-Reply-To: <1508233521.36.0.213398074469.issue31802@psf.upfronthosting.co.za>
Message-ID: <1508241268.19.0.213398074469.issue31802@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +3991
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 07:58:28 2017
From: report at bugs.python.org (Julien Palard)
Date: Tue, 17 Oct 2017 11:58:28 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1508241508.04.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Finally have a combination of latex engines that work for every cases, did a PR on docsbuild-scripts:

https://github.com/python/docsbuild-scripts/pull/34/

I already pulled xelatex on docs.iad1.psf.io via https://github.com/python/psf-salt/commit/989a7715c4a452b5af13baf9a33535bab0af822b#diff-6fb01fe8bbc22a54d234a57ad58e291e

Also opened a few related issue sphinx-doc side to track my thoughts:

- https://github.com/sphinx-doc/sphinx/issues/4150 (Ask if there is a better way to set the latex engine than giving it from docsbuild-scripts)
- https://github.com/sphinx-doc/sphinx/issues/4159 (Choose unicode-enabled default latex engines)
- https://github.com/sphinx-doc/sphinx/issues/4149 (Be more explicit on documentation about how to choose a latex engine)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Tue Oct 17 08:05:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 12:05:57 +0000
Subject: [issue30013] Compiler warning in Modules/posixmodule.c
In-Reply-To: <1491559004.62.0.18619105038.issue30013@psf.upfronthosting.co.za>
Message-ID: <1508241957.88.0.213398074469.issue30013@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry, Louie Lu, this already has been fixed in issue31343.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Include major(), minor(), makedev() from sysmacros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30013>
_______________________________________

From report at bugs.python.org  Tue Oct 17 08:06:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 12:06:54 +0000
Subject: [issue31343] Include major(), minor(), makedev() from sysmacros
In-Reply-To: <1504561837.1.0.90902392889.issue31343@psf.upfronthosting.co.za>
Message-ID: <1508242014.94.0.213398074469.issue31343@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Louie Lu proposed the fix for this issue in issue30013.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31343>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:00:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:00:45 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
Message-ID: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

The behaviour of the time.clock() function is not portable: on Windows it mesures wall-clock, whereas it measures CPU time on Unix. Python has time.process_time() and time.perf_counter(), since Python 3.3, which are portable, well defined and have a better resolution.

time.clock() was deprecated in Python 3.3 documentation, but calling time.clock() didn't raise a DeprecationWarning. I proposed to remove it from Python 3.7.

Sometimes, a deprecated function raises a DeprecationWarning in Python version N, before removing it from Python version N. time.clock() doesn't emit such warning, but I consider that it is possible to remove it anyway.

While it can be annoying to have to patch code to no more use time.clock(), I consider that it's worth it for portability and better clock resolution.

Attached PR removes time.clock() and time.get_clock_info() doens't accept 'clock' anymore.

Current time.clock() documentation:
----------------------------
.. function:: clock()

   .. index::
      single: CPU time
      single: processor time
      single: benchmarking

   On Unix, return the current processor time as a floating point number expressed
   in seconds.  The precision, and in fact the very definition of the meaning of
   "processor time", depends on that of the C function of the same name.

   On Windows, this function returns wall-clock seconds elapsed since the first
   call to this function, as a floating point number, based on the Win32 function
   :c:func:`QueryPerformanceCounter`. The resolution is typically better than one
   microsecond.

   .. deprecated:: 3.3
      The behaviour of this function depends on the platform: use
      :func:`perf_counter` or :func:`process_time` instead, depending on your
      requirements, to have a well defined behaviour.
----------------------------

----------
components: Library (Lib)
messages: 304502
nosy: haypo
priority: normal
severity: normal
status: open
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:05:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:05:58 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508245558.76.0.213398074469.issue31803@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +3992
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:09:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:09:30 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508245770.15.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

With the PR, Python 3.7 will still requires the C clock() function to build on Unix, since time.process_time() uses it as the last fallback if all other functions failed.

Maybe we can require to have other functions used by time.process_time() (clock_gettime(CLOCK_PROF), getrusage(), times(), ...), but I consider that it can be done later. This change may impact the Python portability: compilation error when building Python, see bpo-22624.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:18:30 2017
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 17 Oct 2017 13:18:30 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508246310.82.0.213398074469.issue31803@psf.upfronthosting.co.za>


Change by Fred L. Drake, Jr. <fdrake at gmail.com>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:21:46 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Oct 2017 13:21:46 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508246506.1.0.213398074469.issue31803@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +belopolsky, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:26:35 2017
From: report at bugs.python.org (Ben Hoyt)
Date: Tue, 17 Oct 2017 13:26:35 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508246795.28.0.213398074469.issue31803@psf.upfronthosting.co.za>


Ben Hoyt <benhoyt at gmail.com> added the comment:

I don't think this is a good idea. I still use time.clock() out of habit (on Windows), and from the PR it's clear that the standard library and tests do too. I wouldn't be at all surprised to find others do as well.

I realize it's been deprecated since 3.3, but without a DeprecatingWarning, that's easy to miss. What about adding a DeprecatingWarning for 3.7 and deprecate it later, maybe in 3.9? (I know that's a long time, but time.clock() is an old function so we should be cautious!)

----------
nosy: +benhoyt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:27:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 13:27:17 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508246837.36.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it is better to not remove time.clock() until EOL of 2.7. And in any case it first should start emitting a deprecation warning for a one or two releases.

----------
nosy: +benjamin.peterson, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:35:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:35:26 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508247326.73.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

Ben Hoyt: "... from the PR it's clear that the standard library and tests do too."

I disagree here. The standard library doesn't use time.clock() since Python 3.3. Better clocks like time.perf_counter() or time.monotonic() are now used in the standard library.

My PR onl changes two old tests and the very old turtledemo. I never used turtledemo, I didn't now that it exists neither :-)


"I wouldn't be at all surprised to find others do as well."

Oh, me neither. I'm quite sure that time.clock() is used in the wild. The problem is that you should not use it :-)


"I realize it's been deprecated since 3.3, but without a DeprecatingWarning, that's easy to miss. What about adding a DeprecatingWarning for 3.7 and deprecate it later, maybe in 3.9? (I know that's a long time, but time.clock() is an old function so we should be cautious!)"

I never understood the willingness of DeprecationWarning since almost nobody configures Python to run them. In my experience, even when they are displayed, they are usually ignored until the feature is really removed and then people only really start to look at the issue :-)

But I'm fine with keeping the function and emit a warning in Python 3.7, and remove it from Python 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:38:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 13:38:45 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508247525.12.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

A runtime deprecation warning was not emitted in 3.3 because two alternatives, time.process_time() and time.perf_counter(), were not available before 3.3. It would be hard to write a warning-free code that supports 3.3 and earlier versions at the same time. But now 3.2 is virtually out of use and I think we can start emitting a deprecation warning at runtime.

And maybe make 2to3 replacing time.clock() with time.process_time() or time.perf_counter()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:39:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:39:14 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508247554.31.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

Serhiy: "I think it is better to not remove time.clock() until EOL of 2.7. And in any case it first should start emitting a deprecation warning for a one or two releases."

I really hate using 2.7 EOL as the final countdown to start changing things. Are we building a new "Python 3" chaos where everything explode at once?

IMHO it's not that hard to write code compatible with Python 2 and Python 3:

try:
   from time import perf_counter # Python 3
except ImportError:
   from time import clock as perf_counter # Python 2

time.clock() is probably not the only code which requires two code paths in any non trivial application which wants to stay compatible with Python 2.

time.clock() is usually used for benchmarking. I hope that all benchmarking code was already patched to use time.perf_counter() when available, to make the code portable and get better resolution on Unix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:55:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:55:57 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1508248557.35.0.213398074469.issue31733@psf.upfronthosting.co.za>


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


----------
pull_requests: +3993

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:55:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:55:57 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508248557.58.0.00913614298617.issue31692@psf.upfronthosting.co.za>


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


----------
pull_requests: +3994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 09:56:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 13:56:59 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508248619.16.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

Serhiy: "Isn't worth to document these changes in What's New?"

Ok, I created the PR 4019.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 10:07:22 2017
From: report at bugs.python.org (Mario Corchero)
Date: Tue, 17 Oct 2017 14:07:22 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508249242.42.0.213398074469.issue31800@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Yep, http://man7.org/linux/man-pages/man3/strptime.3.html does support it even if it might look asymetrical.

Example:

           struct tm tm;
           char buf[255];

           memset(&tm, 0, sizeof(struct tm));
           strptime("+00:00", "%z", &tm);
           strftime(buf, sizeof(buf), "%z", &tm);
           puts(buf); // Will print +0000
           exit(EXIT_SUCCESS);

Martin do you want me to "cleanup" the PR, add docs, news entry, etc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Tue Oct 17 10:40:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 14:40:16 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508251216.94.0.213398074469.issue31786@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2c15b29aea5d6b9c61aa42d2c24a07ff1edb4b46 by Serhiy Storchaka (Pablo Galindo) in branch 'master':
bpo-31786: Make functions in the select module blocking when timeout is a small negative value. (#4003)
https://github.com/python/cpython/commit/2c15b29aea5d6b9c61aa42d2c24a07ff1edb4b46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Tue Oct 17 10:46:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 14:46:13 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508251573.29.0.213398074469.issue31786@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: patch review -> backport needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Tue Oct 17 10:59:34 2017
From: report at bugs.python.org (Pox TheGreat)
Date: Tue, 17 Oct 2017 14:59:34 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
Message-ID: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>


New submission from Pox TheGreat <poxthegreat at gmail.com>:

If you start Python by pythonw then sys.stdout and sys.stderr are set to None. If you also use multiprocessing then when the child process finishes BaseProcess._bootstrap calls sys.stdout.flush() and sys.stderr.flush() finally. This causes the process return code to be not zero (it is 1).

----------
components: Library (Lib)
files: process.py.patch
keywords: patch
messages: 304512
nosy: Pox TheGreat
priority: normal
severity: normal
status: open
title: multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)
type: crash
versions: Python 3.5
Added file: https://bugs.python.org/file47224/process.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Tue Oct 17 11:07:29 2017
From: report at bugs.python.org (Mario Corchero)
Date: Tue, 17 Oct 2017 15:07:29 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1508252849.18.0.213398074469.issue24954@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
nosy: +mariocj89

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24954>
_______________________________________

From report at bugs.python.org  Tue Oct 17 12:52:58 2017
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 17 Oct 2017 16:52:58 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508259178.88.0.213398074469.issue31803@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

@Victor: True, people often ignore DeprecationWarning anyway, but that's their problem, at least you can say "well, you were warned". They might not have read the documentation on it recently because they have not felt the need to read again about a function with which they are already familiar.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:03:04 2017
From: report at bugs.python.org (Nathaniel Manista)
Date: Tue, 17 Oct 2017 19:03:04 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1508266984.73.0.213398074469.issue31739@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

As I am learning from the examples, I don't have the confidence to propose a fix to them. :-P

For the IPv4-and-IPv6 "Echo server program": should s be closed at some point after "conn, addr = s.accept()"? Should s be closed on the line immediately after "conn, addr = s.accept()", should it be closed on the last line (after the "with conn:" context is exited), or is either acceptable?

Should the "very simple network sniffer with raw sockets on Windows" have a with statement or "s.close()"? Should the "communicate to a CAN network using the raw socket protocol" example have a with statement or "s.close()"?

Of course it's possible that I'm misunderstanding one or more things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:31:30 2017
From: report at bugs.python.org (Will Starms)
Date: Tue, 17 Oct 2017 19:31:30 +0000
Subject: [issue31782] Add a timeout to multiprocessing's Pool.join
In-Reply-To: <1507922622.85.0.213398074469.issue31782@psf.upfronthosting.co.za>
Message-ID: <1508268690.14.0.213398074469.issue31782@psf.upfronthosting.co.za>


Will Starms <vilhelmen at gmail.com> added the comment:

I've realized that my patch may not be ideal for general-purpose use, but it's a good start for a discussion on the proper way to implement a timeout.

My patch (which is based on a more involved modification to Pool) assumes that the joins after the first will complete within a timely fashion, which is not necessarily true. While this prevents leaving the pool in a half-joined state, it can still get stuck joining other components or at least take significantly longer than the requested timeout.

Assuming that joining an already-joined object is safe, or it can be wrapped in an if statement to check before rejoining, I feel the best solution would be to reduce the timeout as joins complete, either raising (much easier) or returning (like threading.thread, but makes an is_alive function more difficult) when the remaining timeout time hits zero.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31782>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:36:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 19:36:11 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508268971.93.0.213398074469.issue31803@psf.upfronthosting.co.za>


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


----------
pull_requests: +3995

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:36:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 19:36:54 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508269014.46.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

I proposed PR 4020 to emit a DeprecationWarning in time.clock() and time.get_clock_info('clock').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:45:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 19:45:09 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508269509.19.0.213398074469.issue31334@psf.upfronthosting.co.za>


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


New changeset 6cfa927ceb931ad968b5b03e4a2bffb64a8a0604 by Victor Stinner (Riccardo Coccioli) in branch 'master':
bpo-31334: Fix timeout in select.poll.poll() (GH-3277)
https://github.com/python/cpython/commit/6cfa927ceb931ad968b5b03e4a2bffb64a8a0604


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:47:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 19:47:15 +0000
Subject: [issue31805] support._is_gui_available() hangs on x86-64 Sierra 3.6
 buildbot
Message-ID: <1508269635.57.0.213398074469.issue31805@psf.upfronthosting.co.za>


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

http://buildbot.python.org/all/#/builders/20/builds/11

Re-running test 'test_ttk_guionly' in verbose mode
Timeout (0:15:00)!
Thread 0x00007fffc0cd73c0 (most recent call first):
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 485 in _is_gui_available
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 531 in requires
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_ttk_guionly.py", line 8 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 678 in exec_module
  File "<frozen importlib._bootstrap>", line 665 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 955 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 971 in _find_and_load
  File "<frozen importlib._bootstrap>", line 994 in _gcd_import
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/importlib/__init__.py", line 126 in import_module
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 137 in runtest
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 290 in rerun_failed_tests
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 539 in _main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 509 in main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 584 in main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/__main__.py", line 2 in <module>
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", line 85 in _run_code
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", line 193 in _run_module_as_main
make: *** [buildbottest] Error 1

----------
components: Tests, macOS
keywords: buildbot
messages: 304518
nosy: haypo, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: support._is_gui_available() hangs on x86-64 Sierra 3.6 buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31805>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:48:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 19:48:10 +0000
Subject: [issue31805] support._is_gui_available() hangs on x86-64 Sierra
 3.6/3.x buildbot
In-Reply-To: <1508269635.57.0.213398074469.issue31805@psf.upfronthosting.co.za>
Message-ID: <1508269690.45.0.213398074469.issue31805@psf.upfronthosting.co.za>


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

Same issue on x86-64 Sierra 3.x:

http://buildbot.python.org/all/#/builders/14/builds/21

----------
components: +Tkinter
title: support._is_gui_available() hangs on x86-64 Sierra 3.6 buildbot -> support._is_gui_available() hangs on x86-64 Sierra 3.6/3.x buildbot
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31805>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:48:42 2017
From: report at bugs.python.org (Aaron Hall)
Date: Tue, 17 Oct 2017 19:48:42 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1508269722.07.0.213398074469.issue31753@psf.upfronthosting.co.za>


Aaron Hall <aaronchall at yahoo.com> added the comment:

Static analysis:

My mental model currently says the rebuilt function every outer call is an expense with no offsetting benefit. It seems that a function shouldn't build a closure on every call if the closure doesn't close over anything immediately used by the functionality. But I can't explain why the cost doesn't amortize toward zero in my testing.

Usage analysis:

On the other hand, this doesn't seem used very much at all in the std lib.
I'm not sure what the entire global benefit is to moving the closure to be a global instead - but there are about 88000 potential uses of the code on github: https://github.com/search?p=3&q=literal_eval&type=Code&utf8=%E2%9C%93 One use seems to be scanning Python code - so potentially it gets a lot of use?

Alternatively: - to echo Serhiy ("Maybe it is worth to spend some time for optimizing closure creation."), perhaps the matter could be made irrelevant by looking at how we handle closures. I'm not sure why the difference didn't amortize to nearly nothing in my testing - I used Anaconda's Python 3.6.1 distribution on Linux - if that matters.

Potential improvement:

So to be clear, the suggested change would probably be to move _convert to a global, maybe named _literal_eval_convert (this is less half-baked than my first code post, which I somewhat regret. Note that the recursive calls would need to be edited as well as the move and dedent.):


def literal_eval(node_or_string):
    """
    Safely evaluate an expression node or a string containing a Python
    expression.  The string or node provided may only consist of the following
    Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
    sets, booleans, and None.
    """
    if isinstance(node_or_string, str):
        node_or_string = parse(node_or_string, mode='eval')
    if isinstance(node_or_string, Expression):
        node_or_string = node_or_string.body
    return _literal_eval_convert(node_or_string)


def _literal_eval_convert(node):
    if isinstance(node, Constant):
        return node.value
    elif isinstance(node, (Str, Bytes)):
        return node.s
    elif isinstance(node, Num):
        return node.n
    elif isinstance(node, Tuple):
        return tuple(map(_literal_eval_convert, node.elts))
    elif isinstance(node, List):
        return list(map(_literal_eval_convert, node.elts))
    elif isinstance(node, Set):
        return set(map(_literal_eval_convert, node.elts))
    elif isinstance(node, Dict):
        return dict((_literal_eval_convert(k), _literal_eval_convert(v)) for k, v
                    in zip(node.keys, node.values))
    elif isinstance(node, NameConstant):
        return node.value
    elif isinstance(node, UnaryOp) and isinstance(node.op, (UAdd, USub)):
        operand = _literal_eval_convert(node.operand)
        if isinstance(operand, _NUM_TYPES):
            if isinstance(node.op, UAdd):
                return + operand
            else:
                return - operand
    elif isinstance(node, BinOp) and isinstance(node.op, (Add, Sub)):
        left = _literal_eval_convert(node.left)
        right = _literal_eval_convert(node.right)
        if isinstance(left, _NUM_TYPES) and isinstance(right, _NUM_TYPES):
            if isinstance(node.op, Add):
                return left + right
            else:
                return left - right
    raise ValueError('malformed node or string: ' + repr(node))

Note that I am not strongly committed to this issue, and won't feel badly if it is closed. It just seemed to be some low-hanging fruit in the standard library that I happened across.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:50:19 2017
From: report at bugs.python.org (abraithwaite)
Date: Tue, 17 Oct 2017 19:50:19 +0000
Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers
 correctly
In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za>
Message-ID: <1508269819.91.0.213398074469.issue21114@psf.upfronthosting.co.za>


abraithwaite <asbraithwaite at gmail.com> added the comment:

This might have been fixed by https://bugs.python.org/issue22928

Have not tested.

----------
nosy: +abraithwaite

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21114>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:52:40 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Oct 2017 19:52:40 +0000
Subject: [issue31799] Improve __spec__ discoverability
In-Reply-To: <1508163387.44.0.213398074469.issue31799@psf.upfronthosting.co.za>
Message-ID: <1508269960.71.0.213398074469.issue31799@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 191e3138200906e43cba9347177914325b54843f by Barry Warsaw in branch 'master':
bpo-31799: Make module.__spec__ more discoverable (#4010)
https://github.com/python/cpython/commit/191e3138200906e43cba9347177914325b54843f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31799>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:53:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 19:53:25 +0000
Subject: [issue31805] support._is_gui_available() hangs on x86-64 Sierra
 3.6/3.x buildbot
In-Reply-To: <1508269635.57.0.213398074469.issue31805@psf.upfronthosting.co.za>
Message-ID: <1508270005.86.0.213398074469.issue31805@psf.upfronthosting.co.za>


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

Matt: Would you like to look at your buildbot to check if something is wrong with Tkinter?

The code hangs on the CGMainDisplayID() call in support._is_gui_available():

from ctypes import cdll, c_int, pointer, Structure
from ctypes.util import find_library
app_services = cdll.LoadLibrary(find_library("ApplicationServices"))
app_services.CGMainDisplayID()

----------
nosy: +mattbillenstein

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31805>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:53:47 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Oct 2017 19:53:47 +0000
Subject: [issue31799] Improve __spec__ discoverability
In-Reply-To: <1508163387.44.0.213398074469.issue31799@psf.upfronthosting.co.za>
Message-ID: <1508270027.49.0.213398074469.issue31799@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3996

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31799>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:59:23 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Oct 2017 19:59:23 +0000
Subject: [issue31799] Improve __spec__ discoverability
In-Reply-To: <1508163387.44.0.213398074469.issue31799@psf.upfronthosting.co.za>
Message-ID: <1508270363.46.0.213398074469.issue31799@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:


New changeset 858ea4354fafa36e57859d2dfd70f8a057984075 by Barry Warsaw (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31799: Make module.__spec__ more discoverable (GH-4010) (#4021)
https://github.com/python/cpython/commit/858ea4354fafa36e57859d2dfd70f8a057984075


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31799>
_______________________________________

From report at bugs.python.org  Tue Oct 17 15:59:55 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Oct 2017 19:59:55 +0000
Subject: [issue31799] Improve __spec__ discoverability
In-Reply-To: <1508163387.44.0.213398074469.issue31799@psf.upfronthosting.co.za>
Message-ID: <1508270395.27.0.213398074469.issue31799@psf.upfronthosting.co.za>


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


----------
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31799>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:12:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 20:12:30 +0000
Subject: [issue26098] [WIP] PEP 510: Specialize functions with guards
In-Reply-To: <1452689568.12.0.253530674137.issue26098@psf.upfronthosting.co.za>
Message-ID: <1508271150.92.0.213398074469.issue26098@psf.upfronthosting.co.za>


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

I rejected my own PEP 510, so I reject this issue as well.
https://mail.python.org/pipermail/python-dev/2017-October/149901.html

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26098>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:13:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 20:13:15 +0000
Subject: [issue31733] [2.7] Add PYTHONSHOWREFCOUNT environment variable to
 Python 2.7
In-Reply-To: <1507556659.49.0.213398074469.issue31733@psf.upfronthosting.co.za>
Message-ID: <1508271195.26.0.213398074469.issue31733@psf.upfronthosting.co.za>


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


New changeset 355393e7438deeab4aeec3fcffea65e8cada083b by Victor Stinner in branch '2.7':
[2.7] bpo-31733, bpo-31692: Document 2 new env vars in What's New in Python 2.7 (GH-4019)
https://github.com/python/cpython/commit/355393e7438deeab4aeec3fcffea65e8cada083b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31733>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:13:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 20:13:15 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508271195.37.0.912454111764.issue31692@psf.upfronthosting.co.za>


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


New changeset 355393e7438deeab4aeec3fcffea65e8cada083b by Victor Stinner in branch '2.7':
[2.7] bpo-31733, bpo-31692: Document 2 new env vars in What's New in Python 2.7 (GH-4019)
https://github.com/python/cpython/commit/355393e7438deeab4aeec3fcffea65e8cada083b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:14:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 20:14:08 +0000
Subject: [issue31692] [2.7] Test `test_huntrleaks()` of test_regrtest fails in
 debug build with COUNT_ALLOCS
In-Reply-To: <1507131768.17.0.213398074469.issue31692@psf.upfronthosting.co.za>
Message-ID: <1508271248.74.0.213398074469.issue31692@psf.upfronthosting.co.za>


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

I documented the two new environment variables in What's New in Python 2.7, so this issue can now be closed again.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31692>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:25:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 20:25:30 +0000
Subject: [issue26145] [WIP] PEP 511: Add sys.set_code_transformers()
In-Reply-To: <1453108257.94.0.438143755637.issue26145@psf.upfronthosting.co.za>
Message-ID: <1508271930.08.0.213398074469.issue26145@psf.upfronthosting.co.za>


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

I rejected my own PEP 511, so I now reject this issue as well.
https://mail.python.org/pipermail/python-dev/2017-October/149903.html

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26145>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:39:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 20:39:07 +0000
Subject: [issue31234] Make support.threading_cleanup() stricter
In-Reply-To: <1503076378.29.0.950087882836.issue31234@psf.upfronthosting.co.za>
Message-ID: <1508272747.26.0.213398074469.issue31234@psf.upfronthosting.co.za>


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

It seems like all attached PR are now merged. I didn't see any random "dangling thread" warning recently in the master branch, so I close this issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31234>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:40:08 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 17 Oct 2017 20:40:08 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508272808.37.0.213398074469.issue31786@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +3997
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:43:40 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Oct 2017 20:43:40 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1508273020.73.0.213398074469.issue25711@psf.upfronthosting.co.za>


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


----------
pull_requests: +3998

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Tue Oct 17 16:44:56 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Oct 2017 20:44:56 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1508273096.4.0.213398074469.issue25711@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I've ported the patch to a branch on GH.  See PR 4023.  I started from zipimport-2.patch.  It doesn't work, but it will be easier to work on as a PR rather than a patch.

Contributions welcome!  Let's see if we can make this work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:01:50 2017
From: report at bugs.python.org (Aaron Hall)
Date: Tue, 17 Oct 2017 21:01:50 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1508274110.39.0.213398074469.issue31753@psf.upfronthosting.co.za>


Aaron Hall <aaronchall at yahoo.com> added the comment:

New information: I think I have pinpointed at least a contributor to the difference - closure lookups seem to be currently slightly slower (by a few percent) than global lookups (see https://stackoverflow.com/a/46798876/541136). 

And as we can see, an inner function that references itself is a closure on itself (see LOAD_DEREF):

>>> def foo():
...     def bar():
...         return bar
...     return bar
...
>>> bar = foo()
>>> import dis
>>> dis.dis(bar)
  3           0 LOAD_DEREF               0 (bar)
              2 RETURN_VALUE

This, at least to me, explains why the performance difference doesn't completely amortize away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:02:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 21:02:13 +0000
Subject: [issue29696] Use namedtuple in string.Formatter.parse iterator
 response
In-Reply-To: <1488468843.51.0.704010418399.issue29696@psf.upfronthosting.co.za>
Message-ID: <1508274133.31.0.213398074469.issue29696@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not convinced that a named tuple is needed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29696>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:22:20 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 21:22:20 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508275340.03.0.213398074469.issue28603@psf.upfronthosting.co.za>


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

As I understand it, the patch amounts to ignoring any custom __eq__ and __hash__ on an Exception class when printing tracebacks and, in effect, using the default id-based versions inherited from object, as is being assumed.  This seems right to me in this context.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:25:45 2017
From: report at bugs.python.org (Jeff Allen)
Date: Tue, 17 Oct 2017 21:25:45 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1508275545.72.0.213398074469.issue31630@psf.upfronthosting.co.za>


Change by Jeff Allen <ja.py at farowl.co.uk>:


----------
nosy: +jeff.allen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:29:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 21:29:42 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508275782.22.0.213398074469.issue28603@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset de86073a761cd3539aaca6f886a1f55effc0d9da by Serhiy Storchaka (Zane Bitter) in branch 'master':
bpo-28603: Fix formatting tracebacks for unhashable exceptions (#4014)
https://github.com/python/cpython/commit/de86073a761cd3539aaca6f886a1f55effc0d9da


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:30:48 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Oct 2017 21:30:48 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508275848.1.0.213398074469.issue28603@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:46:47 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 21:46:47 +0000
Subject: [issue31803] Remove not portable time.clock(),
 replaced by time.perf_counter() and time.process_time()
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508276807.43.0.213398074469.issue31803@psf.upfronthosting.co.za>


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


New changeset 884d13a55fc328e2e1e3948a82b361b30804b818 by Victor Stinner in branch 'master':
time.clock() now emits a DeprecationWarning (GH-4020)
https://github.com/python/cpython/commit/884d13a55fc328e2e1e3948a82b361b30804b818


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 17:49:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Oct 2017 21:49:06 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508276946.74.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

Ok, I modified time.clock() and time.get_clock_info('clock') to emit a DeprecationWarning.

Let's wait for Python 3.8 to remove time.clock() ;-)

Thanks for the reviews Serhiy Storchaka and Diana Clarke!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:02:24 2017
From: report at bugs.python.org (Florian Weimer)
Date: Tue, 17 Oct 2017 22:02:24 +0000
Subject: [issue31343] Include major(), minor(), makedev() from sysmacros
In-Reply-To: <1504561837.1.0.90902392889.issue31343@psf.upfronthosting.co.za>
Message-ID: <1508277744.39.0.213398074469.issue31343@psf.upfronthosting.co.za>


Change by Florian Weimer <fweimer at redhat.com>:


----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31343>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:06:50 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 22:06:50 +0000
Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt
In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za>
Message-ID: <1508278010.98.0.213398074469.issue30928@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +4000

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30928>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:14:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 22:14:21 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508278461.57.0.213398074469.issue28603@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2712247ec94dcc12cf9abeec78f18f54fcc3357a by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-28603: Fix formatting tracebacks for unhashable exceptions (GH-4014) (#4024)
https://github.com/python/cpython/commit/2712247ec94dcc12cf9abeec78f18f54fcc3357a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:17:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Oct 2017 22:17:00 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1508278620.65.0.213398074469.issue28603@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Zane.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:21:32 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 17 Oct 2017 22:21:32 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
Message-ID: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Following PR for https://bugs.python.org/issue31786 time_sleep, lock_acquire_parse_args and socket_parse_timeout should use _PyTime_ROUND_TIMEOUT instead of _PyTime_ROUND_CEILING.

----------
components: Library (Lib)
messages: 304540
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Use _PyTime_ROUND_TIMEOUT in _threadmodule.c, timemodule.c and socketmodule.c
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:25:08 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 17 Oct 2017 22:25:08 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
In-Reply-To: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>
Message-ID: <1508279108.52.0.213398074469.issue31806@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +4001
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:29:34 2017
From: report at bugs.python.org (Matt Billenstein)
Date: Tue, 17 Oct 2017 22:29:34 +0000
Subject: [issue31805] support._is_gui_available() hangs on x86-64 Sierra
 3.6/3.x buildbot
In-Reply-To: <1508269635.57.0.213398074469.issue31805@psf.upfronthosting.co.za>
Message-ID: <1508279374.8.0.213398074469.issue31805@psf.upfronthosting.co.za>


Matt Billenstein <matt at vazor.com> added the comment:

Did some debugging by sticking a couple prints in support.is_gui_available() and it appears everything is fine up until the call to app_services.SetFrontProcess() -- this is returning error code -606 which is defined in:

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers/MacErrors.h:
appIsDaemon                   = -606, /*app is BG-only, and launch flags disallow this*/

What this means exactly or how to fix it, I don't know...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31805>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:30:26 2017
From: report at bugs.python.org (Matt Billenstein)
Date: Tue, 17 Oct 2017 22:30:26 +0000
Subject: [issue31805] support._is_gui_available() hangs on x86-64 Sierra
 3.6/3.x buildbot
In-Reply-To: <1508269635.57.0.213398074469.issue31805@psf.upfronthosting.co.za>
Message-ID: <1508279426.23.0.213398074469.issue31805@psf.upfronthosting.co.za>


Matt Billenstein <matt at vazor.com> added the comment:

Note, that's running ./python.exe Lib/tests/test_tk.py from a Terminal when logged into the gui...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31805>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:56:20 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 22:56:20 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1508280980.77.0.213398074469.issue13802@psf.upfronthosting.co.za>


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


New changeset e2e42274ee5db1acedf57b63943e1f536d7a25bc by Terry Jan Reedy in branch 'master':
bpo-13802: Use non-Latin characters in IDLE's Font settings sample. (#3960)
https://github.com/python/cpython/commit/e2e42274ee5db1acedf57b63943e1f536d7a25bc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 18:56:27 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Oct 2017 22:56:27 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1508280987.69.0.213398074469.issue13802@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4002

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 19:02:51 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 23:02:51 +0000
Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt
In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za>
Message-ID: <1508281371.37.0.213398074469.issue30928@psf.upfronthosting.co.za>


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


New changeset 27288de0856c6fbe56354adb312ae706ce8bc7de by Terry Jan Reedy in branch 'master':
bpo-30928: Update idlelib/NEWS.txt to 2017 Oct 17. (#4025)
https://github.com/python/cpython/commit/27288de0856c6fbe56354adb312ae706ce8bc7de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30928>
_______________________________________

From report at bugs.python.org  Tue Oct 17 19:02:58 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Oct 2017 23:02:58 +0000
Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt
In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za>
Message-ID: <1508281378.34.0.213398074469.issue30928@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4003

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30928>
_______________________________________

From report at bugs.python.org  Tue Oct 17 19:51:52 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 23:51:52 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1508284312.63.0.213398074469.issue13802@psf.upfronthosting.co.za>


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


New changeset ecacbb4f22ae86d29a73a5f715bce07d091da10d by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-13802: Use non-Latin characters in IDLE's Font settings sample. (GH-3960) (#4027)
https://github.com/python/cpython/commit/ecacbb4f22ae86d29a73a5f715bce07d091da10d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 19:52:32 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 23:52:32 +0000
Subject: [issue13802] IDLE font settings: use multiple character sets in
 examples
In-Reply-To: <1326756140.29.0.0714084996967.issue13802@psf.upfronthosting.co.za>
Message-ID: <1508284352.37.0.213398074469.issue13802@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13802>
_______________________________________

From report at bugs.python.org  Tue Oct 17 19:53:14 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Oct 2017 23:53:14 +0000
Subject: [issue30928] Copy modified blurbs to idlelib/NEWS.txt
In-Reply-To: <1500004288.4.0.547702885246.issue30928@psf.upfronthosting.co.za>
Message-ID: <1508284394.42.0.213398074469.issue30928@psf.upfronthosting.co.za>


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


New changeset 98e0f26f2e4cbf5c2ca27b39f43c1cb0114c6e3c by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-30928: Update idlelib/NEWS.txt to 2017 Oct 17. (GH-4025) (#4028)
https://github.com/python/cpython/commit/98e0f26f2e4cbf5c2ca27b39f43c1cb0114c6e3c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30928>
_______________________________________

From report at bugs.python.org  Tue Oct 17 20:38:16 2017
From: report at bugs.python.org (Chris Angelico)
Date: Wed, 18 Oct 2017 00:38:16 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508287096.33.0.213398074469.issue31780@psf.upfronthosting.co.za>


Chris Angelico <rosuav at gmail.com> added the comment:

Thanks for handling that Terry. I take it the PR isn't needed now?

I would have done it, but I'm on the way to the US (literally posting this from the airport), and hadn't gotten to looking at this in the interval.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Tue Oct 17 20:44:28 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 18 Oct 2017 00:44:28 +0000
Subject: [issue29696] Use namedtuple in string.Formatter.parse iterator
 response
In-Reply-To: <1488468843.51.0.704010418399.issue29696@psf.upfronthosting.co.za>
Message-ID: <1508287468.06.0.213398074469.issue29696@psf.upfronthosting.co.za>


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

It does seem like overkill for something that's rarely used. I'm -0 on the structseq version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29696>
_______________________________________

From report at bugs.python.org  Tue Oct 17 20:48:15 2017
From: report at bugs.python.org (John Villalovos)
Date: Wed, 18 Oct 2017 00:48:15 +0000
Subject: [issue31807] Using autospec=True conflicts with 'wraps'
Message-ID: <1508287695.22.0.213398074469.issue31807@psf.upfronthosting.co.za>


New submission from John Villalovos <john at sodarock.com>:

If have autospec=True, then no ValueError is raised. If autospec=False or not defined, then the ValueError is raised.


import sys
from unittest import mock

def wrapped_func(value):
    raise ValueError(value)

@mock.patch('__main__.wrapped_func', autospec=True, wraps=wrapped_func)
def main(mock_wrap):

    wrapped_func("testing")

if '__main__' == __name__:
    sys.exit(main())

----------
components: Library (Lib)
messages: 304549
nosy: John Villalovos
priority: normal
severity: normal
status: open
title: Using autospec=True conflicts with 'wraps'
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31807>
_______________________________________

From report at bugs.python.org  Tue Oct 17 21:43:52 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 18 Oct 2017 01:43:52 +0000
Subject: [issue31798] `site.abs__file__` fails for modules where `__file__`
 cannot be modified
In-Reply-To: <1508151616.4.0.213398074469.issue31798@psf.upfronthosting.co.za>
Message-ID: <1508291032.55.0.213398074469.issue31798@psf.upfronthosting.co.za>


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

I don't have clr installed in order to test this. It would be good if you could produce it without us having to install additional software.

Could you please copy the entire stack traceback you get when this error occurs?

Does this error happen on 3.6, too?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31798>
_______________________________________

From report at bugs.python.org  Tue Oct 17 21:47:12 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 18 Oct 2017 01:47:12 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1508291232.47.0.213398074469.issue31676@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 178148025494c4058571831fb11fc8eeff8b7365 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-31676: Fix test_imp.test_load_source() side effect (GH-3871) (GH-3988)
https://github.com/python/cpython/commit/178148025494c4058571831fb11fc8eeff8b7365


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Tue Oct 17 22:05:13 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Oct 2017 02:05:13 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1508266984.73.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <20171018020508.BD18B1B10002@webabinitio.net>


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

I think in the echo examples the 'with conn' block should be indented and a
'with s:' added around it.

The network sniffer should probably use a with statement with the
created socket.

The CAN example ends only on ctrl-C, and could go into a fast spin
loop on error, so it probably needs a more extensive rewrite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Tue Oct 17 22:12:55 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Oct 2017 02:12:55 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1508292775.18.0.213398074469.issue31739@psf.upfronthosting.co.za>


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

Heh, of course the socket server also only ends with ctl-C.  And I misread the CAN example, it won't spin because the read isn't wrapped in a try/except.  So yes, that should use a with on the socket as well, since the with will close the socket on a ctl-C, unlike a close statement after the loop which will never be reached.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Wed Oct 18 00:09:08 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Oct 2017 04:09:08 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1508299748.57.0.213398074469.issue31753@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I question those timings.  Here's the results from a script I've been using for many years:

$ python3.6 variable_access.py
0.065	read_local
0.068	read_nonlocal
0.179	read_global
0.236	read_builtin
0.267	read_classvar
0.392	read_instancevar
0.291	read_unboundmethod
0.383	read_boundmethod
0.077	write_local
0.069	write_nonlocal
0.240	write_global
1.154	write_classvar
0.540	write_instance

See the attached timing script:  variable_access.py

Also, take a look at the underlying code:

        #define GETLOCAL(i)     (fastlocals[i])

        TARGET(LOAD_FAST) {
            PyObject *value = GETLOCAL(oparg);
            if (value == NULL) {
                ...
            }
            Py_INCREF(value);
            PUSH(value);
            FAST_DISPATCH();
        }

        #define PyCell_GET(op) (((PyCellObject *)(op))->ob_ref)

        TARGET(LOAD_DEREF) {
            PyObject *cell = freevars[oparg];
            PyObject *value = PyCell_GET(cell);
            if (value == NULL) {
                ...
            }
            Py_INCREF(value);
            PUSH(value);
            DISPATCH();
        }

You can see that the only difference is that LOAD_DEREF has one extra indirection.  That should be very cheap.   In contrast, a LOAD_GLOBAL does a lot more work.  If this isn't evident in your timings, I suspect there is something wrong with the timings.

----------
Added file: https://bugs.python.org/file47225/variable_access.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Wed Oct 18 01:07:19 2017
From: report at bugs.python.org (John Villalovos)
Date: Wed, 18 Oct 2017 05:07:19 +0000
Subject: [issue31807] unitest.mock: Using autospec=True conflicts with 'wraps'
In-Reply-To: <1508287695.22.0.213398074469.issue31807@psf.upfronthosting.co.za>
Message-ID: <1508303239.94.0.213398074469.issue31807@psf.upfronthosting.co.za>


Change by John Villalovos <john at sodarock.com>:


----------
title: Using autospec=True conflicts with 'wraps' -> unitest.mock: Using autospec=True conflicts with 'wraps'

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31807>
_______________________________________

From report at bugs.python.org  Wed Oct 18 01:53:21 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 Oct 2017 05:53:21 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508306001.64.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

time.cock() is used in a lot of code. Why can't we simply replace the functionality with one of the other functions ?

The documentation certainly allows for such a change, since it pretty much just says that only the delta between two values has a meaning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 02:32:01 2017
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Oct 2017 06:32:01 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508308321.26.0.213398074469.issue31803@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I agree with MAL; removing functions just makes multi-version code more painful.  At least have the DeprecationWarning active for two releases before removing it.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 03:13:11 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 07:13:11 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
In-Reply-To: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>
Message-ID: <1508310791.95.0.213398074469.issue31806@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 59af94fa61bf90adbe624508e909b5d6ef6e8464 by Serhiy Storchaka (Pablo Galindo) in branch 'master':
bpo-31806: Use _PyTime_ROUND_TIMEOUT for the timeout argument parsing in more functions (#4026)
https://github.com/python/cpython/commit/59af94fa61bf90adbe624508e909b5d6ef6e8464


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Wed Oct 18 03:13:23 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Oct 2017 07:13:23 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
In-Reply-To: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>
Message-ID: <1508310803.28.0.213398074469.issue31806@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Wed Oct 18 03:58:16 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 18 Oct 2017 07:58:16 +0000
Subject: [issue31780] Using format spec ',x' displays incorrect error message
In-Reply-To: <1507894615.97.0.213398074469.issue31780@psf.upfronthosting.co.za>
Message-ID: <1508313496.5.0.213398074469.issue31780@psf.upfronthosting.co.za>


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

Correct.  Fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31780>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:08:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 08:08:37 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508314117.48.0.213398074469.issue31786@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:12:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 08:12:49 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508314369.52.0.213398074469.issue31786@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 95602b368b87da3702a0f340ded2a23e823bb104 by Serhiy Storchaka (Pablo Galindo) in branch '3.6':
[3.6] bpo-31786: Make functions in the select module blocking when timeout is a small negative value. (GH-4003). (#4022)
https://github.com/python/cpython/commit/95602b368b87da3702a0f340ded2a23e823bb104


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:13:36 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Oct 2017 08:13:36 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
In-Reply-To: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>
Message-ID: <1508314416.07.0.213398074469.issue31806@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:13:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 08:13:52 +0000
Subject: [issue31676] test.test_imp.ImportTests.test_load_source has side
 effects
In-Reply-To: <1507034767.15.0.213398074469.issue31676@psf.upfronthosting.co.za>
Message-ID: <1508314432.83.0.213398074469.issue31676@psf.upfronthosting.co.za>


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

I tested "./python -m test -uall -M4G test_imp test_cgitb" on 3.6 and the master branch. Both tests now pass correctly. I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31676>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:14:33 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Oct 2017 08:14:33 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508314473.84.0.213398074469.issue31334@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:28:00 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 08:28:00 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508315280.52.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

Marc Andre Lemburg: "time.cock() is used in a lot of code. Why can't we simply replace the functionality with one of the other functions ? The documentation certainly allows for such a change, since it pretty much just says that only the delta between two values has a meaning."

Currently time.clock() is the same clock than time.perf_counter() on Windows, but it's closer to CPU time as time.process_time() on Unix.

time.perf_counter() and time.process_time() have a different name because the they are different clocks and don't measure the same thing. The main obvious difference is that time.process_time() doesn't include time elapsed during sleep.

>>> import time
>>> c1=time.perf_counter(); p1=time.process_time(); time.sleep(1); c2=time.perf_counter(); p2=time.process_time()
>>> c2-c1, p2-p1
(1.0010841980038094, 7.308599999999998e-05)

I don't see how to modify clock() to make it behave the same on Windows and Unix without breaking any application which relies on the current clock() behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:28:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 08:28:41 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508315321.02.0.213398074469.issue31786@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ed267e3305a54eddae8106bdaae2c62d4c3b7db6 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-31786: Make functions in the select module blocking when timeout is a small negative value. (GH-4003). (#4031)
https://github.com/python/cpython/commit/ed267e3305a54eddae8106bdaae2c62d4c3b7db6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:29:35 2017
From: report at bugs.python.org (Frederic Beister)
Date: Wed, 18 Oct 2017 08:29:35 +0000
Subject: [issue31808] tarfile.extractall fails to overwrite symlinks
Message-ID: <1508315375.63.0.213398074469.issue31808@psf.upfronthosting.co.za>


New submission from Frederic Beister <frederic.beister at googlemail.com>:

The fix for https://bugs.python.org/issue10761 somehow didn't make it into 3.5 and later - I have the same behavior as described there in 3.5.1 and 3.6.1 (tested on Ubuntu 16.04)

----------
components: Library (Lib)
messages: 304563
nosy: Frederic Beister
priority: normal
severity: normal
status: open
title: tarfile.extractall fails to overwrite symlinks
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31808>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:34:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 08:34:19 +0000
Subject: [issue31786] In select.poll.poll() ms can be 0 if timeout < 0
In-Reply-To: <1507968428.08.0.213398074469.issue31786@psf.upfronthosting.co.za>
Message-ID: <1508315659.85.0.213398074469.issue31786@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Pablo.

The issue is fixed in 3.6 and 3.7. It is hard to fix it in 2.7.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31786>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:45:41 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 08:45:41 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508316341.22.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

(I reopen the issue since the discussion is not over.)

Marc-Andre Lemburg: "time.cock() is used in a lot of code."

I ran a quick search on GitHub. I found different use cases of time.clock():

1) Measure performance. On Windows, time.clock() has a very good precision, *much* better than any other clock. For example, time.process_time() has a resolution of 15.6 ms whereas time.clock() has a resolution of 100 ns (or 0.0001 ms):
https://www.python.org/dev/peps/pep-0564/#windows


2) An explicit check that time.clock() doesn't include sleep. I guess that people are using such snippet to explain this behaviour?

https://github.com/pbarton666/PES_Python_examples_and_solutions/blob/master/py_time.py

---

#py_time.py

import time
print(time.clock(), time.time())
time.sleep(1)  #seconds
print(time.clock(), time.time())
---


Ethan: "I agree with MAL; removing functions just makes multi-version code more painful."

We have two choices:

* Deprecate and then remove time.clock(): break the backward compatibility -- currently chosen solution
* Modify time.clock() to get a portable behaviour: break the backward compatibility

Depending which clock we choose for time.clock(), we may break more and less code, I would vote for using the time.perf_counter() clock in time.clock(). It means no change on Windows, but modify the behaviour on Unix if the code sleeps (time.sleep or I/O).

It seems like time.clock() is mostly used for benchmarking, and time.perf_counter() is documented as the best clock for such use case. In the benchmarks I saw on GitHub, the benchmarked code didn't sleep, it was more likely pure CPU-bound.


Marc-Andre, Ethan: What do you think of removing the deprecation warning from the C (my last commit), leave the deprecation warning in the documentation, and modify time.clock() to become an alias to time.perf_counter()?

By alias, I really mean time.clock = time.perf_counter, so time.clock.__name__ would say "perf_counter".

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 04:46:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 08:46:35 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1508316395.7.0.213398074469.issue30156@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe the difference is processor depending. I'm going to repeat benchmarking on 32-bit processors. Or maybe fast call was optimized in master. Or passing via an arguments tuple was pessimized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Wed Oct 18 05:09:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 09:09:00 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508317740.52.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Initially the time module was a thin wrapper around C and OS time-related functions. It may be confusing that the behavior of time.clock() differs from the behavior of C's clock().

The documentation for clock() on MSDN suggests to use GetProcessTimes() for the behavior conforming the C standard.

https://msdn.microsoft.com/en-us/library/4e2ess30.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 05:10:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 09:10:02 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
In-Reply-To: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>
Message-ID: <1508317802.84.0.213398074469.issue31806@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset be4e9cc769aac3cb46670c049b9f21e412be53d1 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31806: Use _PyTime_ROUND_TIMEOUT for the timeout argument parsing in more functions (GH-4026) (#4032)
https://github.com/python/cpython/commit/be4e9cc769aac3cb46670c049b9f21e412be53d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Wed Oct 18 05:15:42 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 09:15:42 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508318142.67.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

"Initially the time module was a thin wrapper around C and OS time-related functions. It may be confusing that the behavior of time.clock() differs from the behavior of C's clock()."

Well, there is the theory, and there is the practice. Someone decided to implement time.clock() with QueryPerformanceCounter() on Windows, and so time.clock() is no more a thin wrapper to the C clock() function since at least Python 2.7 (I didn't check earlier versions).

Portability on clocks is even more than complex than in the os module, especially when you want the same behaviour on Windows and Unix. The PEP 418 added new clocks with a better defined behaviour to "fix" this issue.


"The documentation for clock() on MSDN suggests to use GetProcessTimes() for the behavior conforming the C standard."

time.process_time() is implemented with GetProcessTimes(). That's why time.clock() suggests to either replace it with time.perf_counter() or time.process_time().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 05:29:19 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 18 Oct 2017 09:29:19 +0000
Subject: [issue29696] Use namedtuple in string.Formatter.parse iterator
 response
In-Reply-To: <1488468843.51.0.704010418399.issue29696@psf.upfronthosting.co.za>
Message-ID: <1508318959.95.0.213398074469.issue29696@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

IMHO this change makes things a bit more consistent. In lots of places when a tuple is returned, a `structseq` is used to improve readability on the returned result. Some examples of this are:

* grp.struct_group
* os.terminal_size
* pwd.struct_passwd
* resource.struct_rusage
* signal.struct_siginfo
* time.struct_time
* spwd.struct_spwd
* sys.float_info
* sys.int_info
* string.FormatterItem
* sys.hash_info
* sys.getwindowsversion
* sys.flags
* sys.version_info
* sys.thread_info

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29696>
_______________________________________

From report at bugs.python.org  Wed Oct 18 05:30:37 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 18 Oct 2017 09:30:37 +0000
Subject: [issue29696] Use namedtuple in string.Formatter.parse iterator
 response
In-Reply-To: <1488468843.51.0.704010418399.issue29696@psf.upfronthosting.co.za>
Message-ID: <1508319037.11.0.213398074469.issue29696@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

With the exception of string.FormatterItem, which is the change at hand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29696>
_______________________________________

From report at bugs.python.org  Wed Oct 18 06:08:54 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 Oct 2017 10:08:54 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508316341.22.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <fbaf28d0-da1f-9e0b-d907-0987382040ff@egenix.com>


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

On 18.10.2017 11:45, STINNER Victor wrote:
> Marc-Andre, Ethan: What do you think of removing the deprecation warning from the C (my last commit), leave the deprecation warning in the documentation, and modify time.clock() to become an alias to time.perf_counter()?
> 
> By alias, I really mean time.clock = time.perf_counter, so time.clock.__name__ would say "perf_counter".

That's what I think would be a better solution, since the
absolute value of time.clock() is never used, only the difference.

If you then get better accuracy in that difference, things
can only get better, so this is not really backwards compatibility
issue (nothing gets worse).

Not sure whether the function name would cause an incompatibility
issue. I doubt it, but if it does we could have time.clock()
as function which then simply calls time.perf_counter().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 18 07:24:06 2017
From: report at bugs.python.org (Riccardo Coccioli)
Date: Wed, 18 Oct 2017 11:24:06 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508325846.35.0.213398074469.issue31334@psf.upfronthosting.co.za>


Change by Riccardo Coccioli <rcoccioli at gmail.com>:


----------
pull_requests: +4008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Wed Oct 18 07:54:54 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Oct 2017 11:54:54 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1508327694.66.0.213398074469.issue31778@psf.upfronthosting.co.za>


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

"Safely evaluate an expression node or a string containing a Python expression."

The behavior you are citing matches that documentation, as far as I can see.  1+1 is an expression involving supported literals.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Wed Oct 18 08:01:29 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 12:01:29 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1508328089.66.0.213398074469.issue31778@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

"""
The string or node provided may only consist of the following Python literal structures: strings, bytes, numbers, tuples, lists, dicts, sets, booleans, and None.
"""

1+1 is not a literal number.

"""
It is not capable of evaluating arbitrarily complex expressions, for example involving operators or indexing.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Wed Oct 18 08:04:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 12:04:08 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508328248.6.0.213398074469.issue31334@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 27b951c63353345cdf7a9a8c4c8133a5dafd6a80 by Serhiy Storchaka (Riccardo Coccioli) in branch '2.7':
[2.7] bpo-31334: Fix timeout in select.poll.poll() (GH-3277) (#4034)
https://github.com/python/cpython/commit/27b951c63353345cdf7a9a8c4c8133a5dafd6a80


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Wed Oct 18 08:05:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 12:05:03 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508328303.27.0.213398074469.issue31334@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Wed Oct 18 08:05:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 12:05:18 +0000
Subject: [issue31334] select.poll.poll fails on BSDs with arbitrary negative
 timeouts
In-Reply-To: <1504477302.52.0.907125806139.issue31334@psf.upfronthosting.co.za>
Message-ID: <1508328318.51.0.213398074469.issue31334@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 97abcabc195b87d6a5562dbb867a469fac27d3f6 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31334: Fix timeout in select.poll.poll() (GH-3277) (#4033)
https://github.com/python/cpython/commit/97abcabc195b87d6a5562dbb867a469fac27d3f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31334>
_______________________________________

From report at bugs.python.org  Wed Oct 18 08:10:20 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 12:10:20 +0000
Subject: [issue31806] Use _PyTime_ROUND_TIMEOUT in _threadmodule.c,
 timemodule.c and socketmodule.c
In-Reply-To: <1508278892.53.0.213398074469.issue31806@psf.upfronthosting.co.za>
Message-ID: <1508328620.93.0.213398074469.issue31806@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31806>
_______________________________________

From report at bugs.python.org  Wed Oct 18 08:19:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 12:19:04 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1508329144.69.0.213398074469.issue14465@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
components: +XML
nosy: +serhiy.storchaka
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Wed Oct 18 09:15:40 2017
From: report at bugs.python.org (A)
Date: Wed, 18 Oct 2017 13:15:40 +0000
Subject: [issue31809] ssl module unnecessarily pins the client curve when
 using ECDH
Message-ID: <1508332540.28.0.213398074469.issue31809@psf.upfronthosting.co.za>


New submission from A <grrrrrrrrr at surfsup.at>:

When using elliptic curves in combination with the ssl module to wrap a socket, the only curve the client accepts is prime256v1. Expected behavior is to accept all curves that are on the default list and supported by the server.

We noticed the issue when connecting to a server that is configured with a non standard curve, we get

[SSL: WRONG_CURVE] wrong curve (_ssl.c:661)

unless we explicitly specify to use the correct curve for the context using

context.set_ecdh_curve("secp521r1")

The bug happens both when using a context or ssl.wrap_socket directly.



The bug is that cpython calls OpenSSL (or whatever lib is linked) server methods even when the context is purely for client communications. The flow is:

- A ssl.SSLContext gets instantiated that will later be used in SSLContext.wrap_socket with server_side either True or False (bug happens when this is client side, so server_side=False).

- In the context's constructor, where it's not yet clear if the context is for a client or a server socket, there is this code:
https://github.com/python/cpython/blob/b9a860f3bf80b0d4a6c25d0f2f6ef849d9bf3594/Modules/_ssl.c#L2180

That code calls (in many cases, depending on the Python and OpenSSL versions involved) server side only methods, SSL_CTX_set_ecdh_auto or SSL_CTX_set_tmp_ecdh.

Those methods should in theory not influence the client side of the context, there is even a comment in the docs for SSLContext.set_ecdh_curve which does similar things that says "This setting doesn?t apply to client sockets". However, this being OpenSSL, this is not true. The methods actually set the list of acceptable curves that is used for both, server and client side connections, to exactly a single curve, prime256v1. This happens for both, SSL_CTX_set_tmp_ecdh and SSL_CTX_set_ecdh_auto.


Versions affected:

OpenSSL has changed the API twice here. Before 1.0.2, SSL_CTX_set_tmp_ecdh was mandatory, 1.0.2 - <1.1.0 used SSL_CTX_set_ecdh_auto and 1.1.0+ doesn't need this setting at all.

Python 2.7.14+ added a check for 1.1.0+ in https://github.com/python/cpython/commit/f1a696efd6ca674579e25de29ec4053ff5a5ade1 so starting from that version the issue only happens when using OpenSSL <1.1.0. I suspect this is the case for many machines still, including all Macs (haven't confirmed the actual bug there). For LibreSSL the server side methods will be called too, I can't confirm if that combination is vulnerable too.

Python 3.5.3 gives me the same error, no reason to believe that higher versions are not affected.

----------
assignee: christian.heimes
components: SSL
messages: 304577
nosy: christian.heimes, grrrrrrrrr
priority: normal
severity: normal
status: open
title: ssl module unnecessarily pins the client curve when using ECDH
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31809>
_______________________________________

From report at bugs.python.org  Wed Oct 18 09:54:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 13:54:07 +0000
Subject: [issue29854] Segfault when readline history is more then 2 * history
 size
In-Reply-To: <1489961724.11.0.51675334909.issue29854@psf.upfronthosting.co.za>
Message-ID: <1508334847.58.0.213398074469.issue29854@psf.upfronthosting.co.za>


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

FYI I added the test.pythoninfo utility as a follow-up of this issue to log many informations to debug Python, not only the readline version: see bpo-30871.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29854>
_______________________________________

From report at bugs.python.org  Wed Oct 18 10:06:53 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 18 Oct 2017 14:06:53 +0000
Subject: [issue31809] ssl module unnecessarily pins the client curve when
 using ECDH
In-Reply-To: <1508332540.28.0.213398074469.issue31809@psf.upfronthosting.co.za>
Message-ID: <1508335613.33.0.213398074469.issue31809@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Which version of OpenSSL are you using? Please note that macOS' system python uses either an ancient version of OpenSSL 0.9.8 or an ancient version of LibreSSL (IIRC 2.3.x).

The code in question is:

if !defined(OPENSSL_NO_ECDH) && !defined(OPENSSL_VERSION_1_1)
    /* Allow automatic ECDH curve selection (on OpenSSL 1.0.2+), or use
       prime256v1 by default.  This is Apache mod_ssl's initialization
       policy, so we should be safe. OpenSSL 1.1 has it enabled by default.
     */
#if defined(SSL_CTX_set_ecdh_auto)
    SSL_CTX_set_ecdh_auto(self->ctx, 1);
#else
    {
        EC_KEY *key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
        SSL_CTX_set_tmp_ecdh(self->ctx, key);
        EC_KEY_free(key);
    }
#endif
#endif

The block is executed for all SSLContexts (server and client) because . The behavior depends on the version of OpenSSL:

OpenSSL >= 1.1: not executed
OpenSSL >= 1.0.2, < 1.1: SL_CTX_set_ecdh_auto(ctx, 1)
LibreSSL: SSL_CTX_set_ecdh_auto(ctx, 1)
OpenSSL < 1.0.2: hard-code prime256v1

Since we have no mean to distinguish between a server context and a client context at the moment, we unconditionally call SSL_CTX_set_ecdh_auto(). It may not be perfect under some condition. But it gives most users a sane and secure default to start with.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_ecdh_auto.html

----------
nosy: +alex, dstufft, janssen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31809>
_______________________________________

From report at bugs.python.org  Wed Oct 18 10:34:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 14:34:06 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1508337246.8.0.213398074469.issue31778@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4009
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Wed Oct 18 10:35:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 14:35:31 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1508337331.27.0.213398074469.issue31778@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 4035 makes ast.literal_eval() more strict.

----------
versions:  -Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Wed Oct 18 11:10:20 2017
From: report at bugs.python.org (Andy)
Date: Wed, 18 Oct 2017 15:10:20 +0000
Subject: [issue31809] ssl module unnecessarily pins the client curve when
 using ECDH
In-Reply-To: <1508332540.28.0.213398074469.issue31809@psf.upfronthosting.co.za>
Message-ID: <1508339420.71.0.213398074469.issue31809@psf.upfronthosting.co.za>


Andy <grrrrrrrrr at surfsup.at> added the comment:

While debugging I reproduced this on
- 'OpenSSL 1.1.0f  25 May 2017'
- 'OpenSSL 1.0.1f 6 Jan 2014'
- and 'BoringSSL', latest.

using Python 2.7.12, 2.7.13, 2.7.6 and 3.5.3. This was all on Debian.


Note that since I used Python <2.7.14 (or equivalent for 3.x) for all tests, the check "... && !defined(OPENSSL_VERSION_1_1)" is missing and therefore the bug *always* triggers regardless of OpenSSL version.



I'm not sure I agree that this one curve is a good default. Note that openssl has 81 curves currently (openssl ecparam -list_curves) and probably can use most of them to connect to a server - accommodating a variety of server setups. Restricting this list to one single curve seems suboptimal.

Think about it like this, if tomorrow we find an issue with that particular curve, all servers can just migrate to a different one and all clients will be able to connect just fine - except those that use Python, they will not be able to talk to those servers ever again until they are upgraded. I mean in the end it's your call but having a *client* just accepting one single security parameter and nothing else doesn't seem right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31809>
_______________________________________

From report at bugs.python.org  Wed Oct 18 11:22:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 15:22:59 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
Message-ID: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>


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

Recently, a new "cell_set_contents()" public symbol was added by mistake: see bpo-30486. It was quickly noticed by doko, and fixed by me (commit 0ad05c32cc41d4c21bfd78b9ffead519ead475a2).

The problem is that we already have a "make smelly" command to check if Python "leaks" symbols, but this check is not run on our CIs (Travis CI or buildbots).

It would be nice to run automatically this test.

----------
components: Tests
keywords: buildbot
messages: 304582
nosy: haypo, zach.ware
priority: normal
severity: normal
status: open
title: Travis CI, buildbots: run "make smelly" to check if CPython leaks symbols
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Wed Oct 18 11:32:03 2017
From: report at bugs.python.org (Colin Dunklau)
Date: Wed, 18 Oct 2017 15:32:03 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
Message-ID: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>


New submission from Colin Dunklau <colin.dunklau at gmail.com>:

I see that code making async/await real keywords has been merged, but it looks like Doc/reference/lexical_analysis.rst doesn't have those added
https://github.com/python/cpython/blob/4a2d00c/Doc/reference/lexical_analysis.rst#keywords            

Is that list autogenerated somehow or was it just overlooked?

----------
assignee: docs at python
components: Documentation
messages: 304583
nosy: Colin Dunklau, docs at python
priority: normal
severity: normal
status: open
title: async and await missing from keyword list in lexical analysis doc
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Wed Oct 18 11:42:17 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Oct 2017 15:42:17 +0000
Subject: [issue31812] Document PEP 545 (documentation translation) in What's
 New in Python 3.7
Message-ID: <1508341337.17.0.213398074469.issue31812@psf.upfronthosting.co.za>


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

The PEP 545 should be documented in What's New in Python 3.7: mention that the Python documentation is now *officially* translated to french and japanese.

----------
assignee: docs at python
components: Documentation
messages: 304584
nosy: docs at python, haypo, inada.naoki, mdk
priority: normal
severity: normal
status: open
title: Document PEP 545 (documentation translation) in What's New in Python 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31812>
_______________________________________

From report at bugs.python.org  Wed Oct 18 11:42:58 2017
From: report at bugs.python.org (Serhy Pyton)
Date: Wed, 18 Oct 2017 15:42:58 +0000
Subject: [issue31813] python -m enshure pip stucks
Message-ID: <1508341378.28.0.213398074469.issue31813@psf.upfronthosting.co.za>


New submission from Serhy Pyton <serhypyton at gmail.com>:

pip stucks, during installing python 3.6.3 in termux and not complete it. Posibly it's could be a problem only on meizu m2. Also it produse load in such state.

----------
components: Installation
files: S71018-182104.jpg
messages: 304585
nosy: Serhy Pyton
priority: normal
severity: normal
status: open
title: python -m enshure pip stucks
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47226/S71018-182104.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31813>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:09:04 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 18 Oct 2017 16:09:04 +0000
Subject: [issue31809] ssl module unnecessarily pins the client curve when
 using ECDH
In-Reply-To: <1508332540.28.0.213398074469.issue31809@psf.upfronthosting.co.za>
Message-ID: <1508342944.17.0.213398074469.issue31809@psf.upfronthosting.co.za>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +4010
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31809>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:10:00 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 18 Oct 2017 16:10:00 +0000
Subject: [issue31809] ssl module unnecessarily pins the client curve when
 using ECDH
In-Reply-To: <1508332540.28.0.213398074469.issue31809@psf.upfronthosting.co.za>
Message-ID: <1508343000.47.0.213398074469.issue31809@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

- BoringSSL is not a supported libssl/libcrypto library for Python. We only support 100% OpenSSL-compatible libraries.
- OpenSSL 1.0.1 is no longer supported by upstream. Python's semi-official support policy for 1.0.1 and 0.9.8 is "use at your own risk". You should upgrade.
- Python < 2.7.13 does not support OpenSSL 1.1
- Python >= 2.7.13 has #if !defined(OPENSSL_VERSION_1_1) before SSL_CTX_set_ecdh_auto()

I added a new test that verifies connections with various curve settings. I cannot reproduce your problem with the test case.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31809>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:24:24 2017
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 18 Oct 2017 16:24:24 +0000
Subject: [issue31814] subprocess_fork_exec more stable with vfork
Message-ID: <1508343864.17.0.213398074469.issue31814@psf.upfronthosting.co.za>


New submission from Albert Zeyer <albzey at googlemail.com>:

subprocess_fork_exec currently calls fork().

I propose to use vfork() or posix_spawn() or syscall(SYS_clone, SIGCHLD, 0) instead if possible and if there is no preexec_fn. The difference would be that fork() will call any atfork handlers (registered via pthread_atfork()), while the suggested calls would not.

There are cases where atfork handlers are registered which are not save to be called e.g. in multi-threaded environments. In the case of subprocess_fork_exec without preexec_fn, there is no need to call those atfork handlers, so avoiding this could avoid potential problems. It's maybe acceptable if a pure fork() without exec() doesn't work in this case anymore, but there is no reason that a fork()+exec() should not work in any such cases. This is fixed by my proposed solution.

An example case is OpenBlas and OpenMP, which registers an atfork handler which is safe to be called if there are other threads running.
See here:
https://github.com/tensorflow/tensorflow/issues/13802
https://github.com/xianyi/OpenBLAS/issues/240
https://trac.sagemath.org/ticket/22021

About fork+exec without the atfork handlers, see here for alternatives (like vfork):
https://stackoverflow.com/questions/46810597/forkexec-without-atfork-handlers/

----------
components: Interpreter Core
messages: 304587
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: subprocess_fork_exec more stable with vfork
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31814>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:43:01 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 16:43:01 +0000
Subject: [issue31815] Make itertools iterators interrable
Message-ID: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Proposed PR makes tight C loops with itertools iterators interruptible with Ctrl-C. It adds checks for keyboard interrupt in iterators that can produce long sequences without advancing other iterators. For performance checks are performed only for every 0x1000-th item. If for generating new value other iterator should be advanced, the responsibility for checking for keyboard interrupt is attributed to that iterator.

This would solve the problem discussed on Python-ideas:

https://mail.python.org/pipermail/python-ideas/2017-October/047412.html
http://permalink.gmane.org/gmane.comp.python.ideas/47429

Example:

>>> import itertools
>>> it = itertools.count()
>>> it in it
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt
>>>

----------
components: Extension Modules
messages: 304588
nosy: ncoghlan, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Make itertools iterators interrable
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:50:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 16:50:34 +0000
Subject: [issue31815] Make itertools iterators interrable
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508345434.63.0.213398074469.issue31815@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4011

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:51:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 16:51:05 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508345465.69.0.213398074469.issue31815@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: Make itertools iterators interrable -> Make itertools iterators interruptible

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 12:54:55 2017
From: report at bugs.python.org (Wilfred Hughes)
Date: Wed, 18 Oct 2017 16:54:55 +0000
Subject: [issue28339] "TypeError: Parameterized generics cannot be used with
 class or instance checks" in test_functools after importing typing module
In-Reply-To: <1475421693.5.0.638809019729.issue28339@psf.upfronthosting.co.za>
Message-ID: <1508345695.21.0.213398074469.issue28339@psf.upfronthosting.co.za>


Wilfred Hughes <yowilfred at gmail.com> added the comment:

Note that this also affects the singledispatch library that backports singledispatch to Python 2: https://github.com/python/typing/issues/484

----------
nosy: +Wilfred.Hughes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28339>
_______________________________________

From report at bugs.python.org  Wed Oct 18 13:18:46 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 18 Oct 2017 17:18:46 +0000
Subject: [issue31778] ast.literal_eval supports non-literals in Python 3
In-Reply-To: <1507847478.46.0.213398074469.issue31778@psf.upfronthosting.co.za>
Message-ID: <1508347126.29.0.213398074469.issue31778@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy:  -yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31778>
_______________________________________

From report at bugs.python.org  Wed Oct 18 13:29:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Oct 2017 17:29:11 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508347751.22.0.213398074469.issue31815@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 13:34:47 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Oct 2017 17:34:47 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508348087.96.0.213398074469.issue31815@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

When I have time, I would like to re-launch a python-dev discussion on this.  It is my feeling that this solves an invented problem.  In my experience, it only ever happens to people who have intentionally trying to create this effect.

Adding this kind of "junk" through-out the code base adds complexity and more internal operations, but won't help *any* existing, deployed code.  We're making everyone pay for a problem that almost no one has.

Also, if we do care about interruptability, it is unclear whether the responsiblity should like with the consumer or the producer of the iterator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 14:11:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 18:11:40 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508350300.89.0.213398074469.issue31815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Microbenchmark results:

$ ./python -m perf timeit --compare-to=../cpython-release/python -s 'from itertools import repeat' 'list(repeat(None, 1000000))'
/home/serhiy/py/cpython-release/python: ..................... 3.79 ms +- 0.09 ms
/home/serhiy/py/cpython-iter/python: ..................... 4.14 ms +- 0.07 ms

Mean +- std dev: [/home/serhiy/py/cpython-release/python] 3.79 ms +- 0.09 ms -> [/home/serhiy/py/cpython-iter/python] 4.14 ms +- 0.07 ms: 1.09x slower (+9%)


$ ./python -m perf timeit --compare-to=../cpython-release/python -s 'from itertools import cycle, islice' 'list(islice(cycle(range(1000)), 1000000))'
/home/serhiy/py/cpython-release/python: ..................... 6.88 ms +- 0.30 ms
/home/serhiy/py/cpython-iter/python: ..................... 6.87 ms +- 0.26 ms

Mean +- std dev: [/home/serhiy/py/cpython-release/python] 6.88 ms +- 0.30 ms -> [/home/serhiy/py/cpython-iter/python] 6.87 ms +- 0.26 ms: 1.00x faster (-0%)
Not significant!


$ ./python -m perf timeit --compare-to=../cpython-release/python -s 'from itertools import count, islice' 'list(islice(count(), 1000000))'
/home/serhiy/py/cpython-release/python: ..................... 26.1 ms +- 0.6 ms
/home/serhiy/py/cpython-iter/python: ..................... 26.3 ms +- 0.6 ms

Mean +- std dev: [/home/serhiy/py/cpython-release/python] 26.1 ms +- 0.6 ms -> [/home/serhiy/py/cpython-iter/python] 26.3 ms +- 0.6 ms: 1.01x slower (+1%)
Not significant!


$ ./python -m perf timeit --compare-to=../cpython-release/python -s 'from itertools import product' 'list(product(range(100), repeat=3))'
/home/serhiy/py/cpython-release/python: ..................... 80.2 ms +- 3.2 ms
/home/serhiy/py/cpython-iter/python: ..................... 80.2 ms +- 1.7 ms

Mean +- std dev: [/home/serhiy/py/cpython-release/python] 80.2 ms +- 3.2 ms -> [/home/serhiy/py/cpython-iter/python] 80.2 ms +- 1.7 ms: 1.00x faster (-0%)
Not significant!


$ ./python -m perf timeit --compare-to=../cpython-release/python -s 'from itertools import combinations' 'list(combinations(range(23), 10))'
/home/serhiy/py/cpython-release/python: ..................... 177 ms +- 14 ms
/home/serhiy/py/cpython-iter/python: ..................... 169 ms +- 4 ms

Mean +- std dev: [/home/serhiy/py/cpython-release/python] 177 ms +- 14 ms -> [/home/serhiy/py/cpython-iter/python] 169 ms +- 4 ms: 1.05x faster (-4%)


The only significant slowdown is for repeat(). But there is possibility to optimize this one by reusing an existing counter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 14:28:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 18:28:55 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508351335.86.0.213398074469.issue31815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

With optimized repeat():

$ ./python -m perf timeit --compare-to=../cpython-release/python -s 'from itertools import repeat' 'list(repeat(None, 1000000))'
/home/serhiy/py/cpython-release/python: ..................... 3.77 ms +- 0.06 ms
/home/serhiy/py/cpython-iter/python: ..................... 3.77 ms +- 0.05 ms

Mean +- std dev: [/home/serhiy/py/cpython-release/python] 3.77 ms +- 0.06 ms -> [/home/serhiy/py/cpython-iter/python] 3.77 ms +- 0.05 ms: 1.00x faster (-0%)
Not significant!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 14:58:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Oct 2017 18:58:12 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508353092.84.0.213398074469.issue31815@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Raymond. I cited the same arguments in the discussion on Python-ideas. But the other solution that was suggested in this discussion will add more complexity and can't solve all cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 14:58:41 2017
From: report at bugs.python.org (paul j3)
Date: Wed, 18 Oct 2017 18:58:41 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1508353121.75.0.213398074469.issue9253@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

In a recent stackoverflow question a user wanted this optional-subparsers ability in Python 2.7.

https://stackoverflow.com/questions/46667843/how-to-set-a-default-subparser-using-argparse-module-with-python-2-7

Short of modifying the _parse_known_args method, the best I could suggest was a two stage parsing.  That is, one parser without the subparsers.  This uses parse_known_args, and if a 'cmd' is provided passes the 'extras' to one that handles subparsers.

---

Another issue which I don't think has been addressed is the 'usage' when subparsers are optional.  At least with 3.5, subparsers are displayed with the choices: {'cmd1', 'cmd2', ...}, but no indication of being optional.  An optional positional (with ? nargs) would normally be displayed as

     prog [-h] [{'one', 'two'}] ...

My guess is that 'usage' adds the [] when positionals nargs='?', without regard to the 'required' attribute (I should verify this from code).

I'm undecided as to whether we want the brackets or not.  It's more accurate, but makes the usage messier.  And the 'help' grouping for 'optional-positionals' is the subject of other bug/issue(s).

I haven't checked it the patch has changed this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Wed Oct 18 15:43:36 2017
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Oct 2017 19:43:36 +0000
Subject: [issue31742] Default to emitting FutureWarning for provisional APIs
In-Reply-To: <1507600047.89.0.213398074469.issue31742@psf.upfronthosting.co.za>
Message-ID: <1508355816.03.0.213398074469.issue31742@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31742>
_______________________________________

From report at bugs.python.org  Wed Oct 18 16:05:51 2017
From: report at bugs.python.org (Koos Zevenhoven)
Date: Wed, 18 Oct 2017 20:05:51 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508357151.0.0.213398074469.issue31815@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

To repeat one of my points in the linked threads, I'm not convinced that infinite iterators are the most common case for the problem of long uninterruptible loops. A general mechanism that can be easily used in many places with minimal maintenance burden would be nice. It could be used even in third-party extension modules.

----------
nosy: +koos.zevenhoven

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 17:00:00 2017
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 18 Oct 2017 21:00:00 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1508360400.17.0.213398074469.issue24954@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Wrote https://bugs.python.org/issue31800 without realising this issue was open (Thanks for bringing it up Martin Panter).

issue31800 basically just adds the ability to parse NN:NN to the already existing python isoformat function when %z is specified.
Rather than adding "%:z".

As available as well in linux strptime: http://man7.org/linux/man-pages/man3/strptime.3.html

I'd really like to see a way to parse isoformatted dates and this is the only thing in the middle. Happy to continue with the other issue/PR or help out here if needed.

Thanks! ^^

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24954>
_______________________________________

From report at bugs.python.org  Wed Oct 18 17:29:05 2017
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 18 Oct 2017 21:29:05 +0000
Subject: [issue31454] Include "import as" in tutorial
In-Reply-To: <1505317940.24.0.986048971751.issue31454@psf.upfronthosting.co.za>
Message-ID: <1508362145.53.0.213398074469.issue31454@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
nosy: +mariocj89

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31454>
_______________________________________

From report at bugs.python.org  Wed Oct 18 17:38:12 2017
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 18 Oct 2017 21:38:12 +0000
Subject: [issue31454] Include "import as" in tutorial
In-Reply-To: <1505317940.24.0.986048971751.issue31454@psf.upfronthosting.co.za>
Message-ID: <1508362692.56.0.213398074469.issue31454@psf.upfronthosting.co.za>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
keywords: +patch
pull_requests: +4012
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31454>
_______________________________________

From report at bugs.python.org  Wed Oct 18 19:19:15 2017
From: report at bugs.python.org (Stephan Hoyer)
Date: Wed, 18 Oct 2017 23:19:15 +0000
Subject: [issue30140] Binary arithmetic does not always call subclasses first
In-Reply-To: <1492921304.69.0.401017078402.issue30140@psf.upfronthosting.co.za>
Message-ID: <1508368755.43.0.213398074469.issue30140@psf.upfronthosting.co.za>


Stephan Hoyer <shoyer at gmail.com> added the comment:

Ping -- it would be great if someone could take a look at my PR. (I suspect it needs more documentation, tips on where to put that would be appreciated.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30140>
_______________________________________

From report at bugs.python.org  Wed Oct 18 19:52:30 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 18 Oct 2017 23:52:30 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508370750.16.0.213398074469.issue31457@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
pull_requests: +4013

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Wed Oct 18 20:28:59 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 19 Oct 2017 00:28:59 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508372939.11.0.213398074469.issue31457@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 0b6a118a45ac2eded1348fea6ed300d5651f7471 by ?ukasz Langa in branch 'master':
bpo-31457: Make the `LoggerAdapter.manager` property settable (#4042)
https://github.com/python/cpython/commit/0b6a118a45ac2eded1348fea6ed300d5651f7471


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Wed Oct 18 20:30:13 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Oct 2017 00:30:13 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508373013.78.0.213398074469.issue31457@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Wed Oct 18 21:03:01 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 19 Oct 2017 01:03:01 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508374981.15.0.213398074469.issue31457@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 537ed75291ed8a640887f199f98e2e5076ef87b6 by ?ukasz Langa (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31457: Make the `LoggerAdapter.manager` property settable (GH-4042) (#4043)
https://github.com/python/cpython/commit/537ed75291ed8a640887f199f98e2e5076ef87b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Wed Oct 18 21:24:37 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Oct 2017 01:24:37 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508376277.5.0.213398074469.issue31815@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Defensive coding and the complications it brings is a fact of life when providing a widely used platform.

Sure, we're free to say "We don't care about minor user experience irritations like Ctrl-C not always being reliable, users should just suck it up and cope".

I think "It's your own fault for typing that, just restart your session from scratch" is setting the bar too low for ourselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 21:55:31 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Oct 2017 01:55:31 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508378131.34.0.213398074469.issue31815@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To put this another way: I see an uninterruptible infinite loop as a data loss bug on par with a segfault, since there's no graceful way to terminate the process and allow cleanup code to run.

For segfaults, we're willing to tolerate them, but we expect the reproducers to involve arcane coding contortions, not simple expressions like "sum(itertools.count())".

Now, the producer side check that Serhiy posted here only addresses part of the problem - there's also the question of making the consumption loops more robust by having them check for signals, and adding a ThreadExit equivalent to allow the interpreter to request shutdown of non-daemon threads other than the main thread.

But as long as we think it's a-OK for us to hang a user's session, causing them to lose all their unsaved/uncached data, then we're going to resist the extra code complexity required to account for these usability concerns. (And I realise they're not new concerns - they're just longstanding problems that folks have gotten used to tolerating and excusing)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Wed Oct 18 22:10:44 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 19 Oct 2017 02:10:44 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508379044.08.0.213398074469.issue31457@psf.upfronthosting.co.za>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
pull_requests: +4015

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Thu Oct 19 01:34:07 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Oct 2017 05:34:07 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508391247.11.0.213398074469.issue31815@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I respectfully disagree that this just happens to people accidentally -- Every single day, I work with either Python professionals or Python students and never see this situation occur, nor have I had a single report of it from one of my clients, ever.  In my experience, someone has to be trying to produce exactly this effect.  

They have to go out of their way to import a high-performance module, select one of the tools specifically documented to be infinite, specifically reach for one the very few tools like repeat() or count() that don't make any pure python callbacks, and then separately reach for a high-performance consumer that makes no pure python callbacks.  People don't just write ``sum(itertools.count()`` to do something useful, they do it just to see if they can produce exactly this effect.

We have a number of areas where we're comfortable saying "just don't do that" (i.e. the repr of a large number or of a large container, repeated exponentation, bytecode hacks, ill-formed ctypes, etc).

I would like to draw a line in the sand for itertools to not go down this path unless we actually see this happening in the wild to people not trying to do it on purpose.  It is much more likely that a user with accidentally types ">>> 'x' * 1000000000" and gets the same effect.

On a side note, I have a fear (possibly rational, possibly not) that introducing signal handling into formerly atomic operations will open up new classes of bugs and usability problems (i.e. Issue #14976 showed that when GC gained the ability trigger calls to __del__, it created queue reentrancy deadlock problems that could not be solved with pure python code).

One last thought -- the various core devs seem to be charging in opposite directions.  On the one hand, there seems to be no limit to the coding atrocities being considered to save under a millisecond of startup time and for various other questionable mirco-optimizations.  And on the other hand, there seems to be a great deal of willingness to inject almost-never-needed error checks or signal handling into otherwise tight, high-volume code paths.   One group likes to refactor code to make it clean and easy to maintain and stick with its business purpose, while another group is comfortable garbaging-up code in order to achieve some other benefit that may not be in line with the module designer's intent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Thu Oct 19 02:04:54 2017
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 19 Oct 2017 06:04:54 +0000
Subject: [issue31813] python -m enshure pip stucks
In-Reply-To: <1508341378.28.0.213398074469.issue31813@psf.upfronthosting.co.za>
Message-ID: <1508393094.9.0.213398074469.issue31813@psf.upfronthosting.co.za>


Chi Hsuan Yen <yan12125 at gmail.com> added the comment:

Might be caused by this bug: https://github.com/pypa/pip/issues/3532

pip uses lockfile, and lockfile uses hard links, which are prohibited on newer Android versions unless you're root. A workaround is configuring python with |./configure --without-ensurepip|.

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31813>
_______________________________________

From report at bugs.python.org  Thu Oct 19 03:40:29 2017
From: report at bugs.python.org (George King)
Date: Thu, 19 Oct 2017 07:40:29 +0000
Subject: [issue31681] pkgutil.get_data() leaks open files in Python 2.7
In-Reply-To: <1507059584.22.0.213398074469.issue31681@psf.upfronthosting.co.za>
Message-ID: <1508398829.04.0.213398074469.issue31681@psf.upfronthosting.co.za>


Change by George King <george.w.king at gmail.com>:


----------
pull_requests: +4016

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31681>
_______________________________________

From report at bugs.python.org  Thu Oct 19 03:40:42 2017
From: report at bugs.python.org (George King)
Date: Thu, 19 Oct 2017 07:40:42 +0000
Subject: [issue31618] Change sys.settrace opcode tracing to occur after frame
 line number update
In-Reply-To: <1506602403.3.0.466225441844.issue31618@psf.upfronthosting.co.za>
Message-ID: <1508398842.08.0.213398074469.issue31618@psf.upfronthosting.co.za>


Change by George King <george.w.king at gmail.com>:


----------
keywords: +patch
pull_requests: +4017
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31618>
_______________________________________

From report at bugs.python.org  Thu Oct 19 03:41:38 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Oct 2017 07:41:38 +0000
Subject: [issue31785] Move instruction code from ceval.c to a separate file
In-Reply-To: <1507939104.79.0.213398074469.issue31785@psf.upfronthosting.co.za>
Message-ID: <1508398898.45.0.213398074469.issue31785@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

No one has spoken up for this feature request, so I'm marking it as closed.  Thank you for the suggestion, but I think it is prudent to decline.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31785>
_______________________________________

From report at bugs.python.org  Thu Oct 19 03:44:47 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Oct 2017 07:44:47 +0000
Subject: [issue31618] Change sys.settrace opcode tracing to occur after frame
 line number update
In-Reply-To: <1506602403.3.0.466225441844.issue31618@psf.upfronthosting.co.za>
Message-ID: <1508399087.16.0.213398074469.issue31618@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the fix!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31618>
_______________________________________

From report at bugs.python.org  Thu Oct 19 03:48:26 2017
From: report at bugs.python.org (Nils Diefenbach)
Date: Thu, 19 Oct 2017 07:48:26 +0000
Subject: [issue31816] Unexpected behaviour of `dir()` after implementation of
 __dir__
Message-ID: <1508399306.09.0.213398074469.issue31816@psf.upfronthosting.co.za>


New submission from Nils Diefenbach <23okrs20+python at mykolab.com>:

When defining a custom __dir__ method in a class, calling dir() on
said class still sorts the output. This is, imo, unexpected behaviour, especially if the order of output was specified in __dir__ and is somehow relevant.

Example and more detail here
https://stackoverflow.com/questions/46824459/custom-dir-returns-list-of-attributes-sorted-alphabetically

----------
messages: 304606
nosy: nlsdfnbch
priority: normal
severity: normal
status: open
title: Unexpected behaviour of `dir()` after implementation of __dir__
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31816>
_______________________________________

From report at bugs.python.org  Thu Oct 19 03:50:58 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Oct 2017 07:50:58 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508399458.93.0.213398074469.issue31815@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd personally be happy enough if the infinite iterators implemented __length_hint__() as always raising TypeError so the machine-breaking cases of incremental consumption of ever-increasing amounts of memory were blocked - I was suggesting on python-ideas that enabling pervasive signal checking would be too intrusive for anyone to be willing to implement it.

However, Serhiy's patch showed me that it isn't particularly intrusive at all, and the risk of surprising consumers is low, since __next__() methods can already raise arbitrary exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Thu Oct 19 04:03:45 2017
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 19 Oct 2017 08:03:45 +0000
Subject: [issue31816] Unexpected behaviour of `dir()` after implementation of
 __dir__
In-Reply-To: <1508399306.09.0.213398074469.issue31816@psf.upfronthosting.co.za>
Message-ID: <1508400225.38.0.213398074469.issue31816@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

dir() and __dir__ work as designed and documented:

https://docs.python.org/3/reference/datamodel.html?highlight=__dir__#object.__dir__

Called when dir() is called on the object. A sequence must be returned. dir() converts the returned sequence to a list and sorts it

----------
nosy: +christian.heimes
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31816>
_______________________________________

From report at bugs.python.org  Thu Oct 19 04:27:27 2017
From: report at bugs.python.org (Nils Diefenbach)
Date: Thu, 19 Oct 2017 08:27:27 +0000
Subject: [issue31816] Unexpected behaviour of `dir()` after implementation of
 __dir__
In-Reply-To: <1508399306.09.0.213398074469.issue31816@psf.upfronthosting.co.za>
Message-ID: <1508401647.22.0.213398074469.issue31816@psf.upfronthosting.co.za>


Nils Diefenbach <23okrs20+python at mykolab.com> added the comment:

Alright. Are there any other magic methods that do some post-processing on a custom implementation of them ? 

I couldn't think of one, which is why this behaviour appeared odd to me.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31816>
_______________________________________

From report at bugs.python.org  Thu Oct 19 04:35:11 2017
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 19 Oct 2017 08:35:11 +0000
Subject: [issue31816] Unexpected behaviour of `dir()` after implementation of
 __dir__
In-Reply-To: <1508399306.09.0.213398074469.issue31816@psf.upfronthosting.co.za>
Message-ID: <1508402111.79.0.213398074469.issue31816@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

https://docs.python.org/3/library/functions.html#dir also states that "The resulting list is sorted alphabetically." The section has an example where __dir__ returns an unsorted list but dir() returns a sorted list:

>>> class Shape:
...     def __dir__(self):
...         return ['area', 'perimeter', 'location']
>>> s = Shape()
>>> dir(s)
['area', 'location', 'perimeter']

Since the primary purpose of dir() is convenient use for humans, sorting makes perfectly sense. If you need tight control over order of values, you should make your object iterable instead or provide another method.

Several dunder methods perform some sort of post-processing or post-check:

>>> class Example:
...     def __bool__(self): return 2
... 
>>> bool(Example())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __bool__ should return bool, returned int

>>> class MyInt(int):
...     pass
... 
>>> type(MyInt(1))
<class '__main__.MyInt'>
>>> class Example:
...     def __int__(self):
...         return MyInt(1)
... 
>>> int(Example())
1
>>> type(int(Example()))
<class 'int'>

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31816>
_______________________________________

From report at bugs.python.org  Thu Oct 19 05:27:26 2017
From: report at bugs.python.org (raylu)
Date: Thu, 19 Oct 2017 09:27:26 +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: <1508405246.14.0.213398074469.issue17799@psf.upfronthosting.co.za>


Change by raylu <lurayl at gmail.com>:


----------
nosy: +raylu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Thu Oct 19 05:34:19 2017
From: report at bugs.python.org (Wipolun)
Date: Thu, 19 Oct 2017 09:34:19 +0000
Subject: [issue14912] Pdb does not stop at a breakpoint after a restart
 command and source changes
In-Reply-To: <1337945757.27.0.114974346451.issue14912@psf.upfronthosting.co.za>
Message-ID: <1508405659.88.0.213398074469.issue14912@psf.upfronthosting.co.za>


Wipolun <wipolun at asorent.com> added the comment:

Worked for me on https://www.cheshiremouldings.co.uk/stair-parts/

----------
nosy: +wipolun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14912>
_______________________________________

From report at bugs.python.org  Thu Oct 19 06:07:54 2017
From: report at bugs.python.org (Josh Cullum)
Date: Thu, 19 Oct 2017 10:07:54 +0000
Subject: [issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter
Message-ID: <1508407674.96.0.213398074469.issue31817@psf.upfronthosting.co.za>


New submission from Josh Cullum <joshua.cullum at gmail.com>:

Hi Guys,

I'm trying to build Python 3.6.1 and 3.6.3, with both, .configure / make / make install work correctly as they should, however, trying to import _tkinter doesn't work.

Going back to the compilation, I get the following error in the make log:

*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu.so: undefined symbol: Tcl_GetCharLength

Following modules built successfully but were removed because they could not be imported:
_tkinter


Any Idea's on how to fix the undefined symbol error? This happens with both Tcl/Tk 8.6.6 and 8.6.7.

The following is the configure options:
--prefix=/tools/apps/python/3.6.1 --with-tcltk-includes='-I/tools/apps/Tcl/8.6.7/include -I/tools/apps/Tk/8.6.7/include' --with-tcltk-libs='-L/tools/apps/Tcl/8.6.7/lib -L/tools/apps/Tk/8.6.7/lib' --enable-optimizations --enable-shared

----------
components: Tkinter
messages: 304612
nosy: jpc2350
priority: normal
severity: normal
status: open
title: Compilation Error with Python 3.6.1/3.6.3 with Tkinter
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31817>
_______________________________________

From report at bugs.python.org  Thu Oct 19 06:17:55 2017
From: report at bugs.python.org (Albert Zeyer)
Date: Thu, 19 Oct 2017 10:17:55 +0000
Subject: [issue31814] subprocess_fork_exec more stable with vfork
In-Reply-To: <1508343864.17.0.213398074469.issue31814@psf.upfronthosting.co.za>
Message-ID: <1508408275.41.0.213398074469.issue31814@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

This is a related issue, although with different argumentation:
https://bugs.python.org/issue20104

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31814>
_______________________________________

From report at bugs.python.org  Thu Oct 19 06:30:37 2017
From: report at bugs.python.org (Mirko Friedenhagen)
Date: Thu, 19 Oct 2017 10:30:37 +0000
Subject: [issue31818] macOS HighSierra final - Python Crash because of _scproxy
Message-ID: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>


New submission from Mirko Friedenhagen <mfriedenhagen at gmail.com>:

The same bug which shows up in https://bugs.python.org/issue30837 is in both the System python provided by Apple (2.7.10) as well as the one coming via Homebrew (2.7.14) (See https://github.com/Homebrew/homebrew-core/blob/master/Formula/python.rb) for build instructions.

The culprit is the same as before, `_scproxy`. Setting the environment variable `no_proxy` did the trick for me as well. I attached the crash report

----------
components: macOS
files: python2.7_2017-10-18-092216-1_lmka-2hpphfdty3.crash
messages: 304614
nosy: Mirko Friedenhagen, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: macOS HighSierra final - Python Crash because of _scproxy
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47227/python2.7_2017-10-18-092216-1_lmka-2hpphfdty3.crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Thu Oct 19 06:50:50 2017
From: report at bugs.python.org (Andrew Clegg)
Date: Thu, 19 Oct 2017 10:50:50 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1508410250.57.0.213398074469.issue31756@psf.upfronthosting.co.za>


Change by Andrew Clegg <andrew.clegg at durham.ac.uk>:


----------
keywords: +patch
pull_requests: +4018
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Thu Oct 19 08:36:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Oct 2017 12:36:40 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <1508416600.81.0.213398074469.issue31818@psf.upfronthosting.co.za>


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

Hi, can you please explain how to reproduce your issue?

According to the crash report, it seems like you are running Ansible on macOS and that the Python function _scproxy.get_proxies() was called.

get_proxies() calls CFPreferencesCopyAppValue() which calls indirectly performForkChildInitialize(). It seems like Ansible forked the process or something like that. Finally, performForkChildInitialize() calls _objc_fatal() which kills the process with abort().

The parent process is also Python ("Parent Process: python2.7 [4305]") which confirms that the application used fork().

See also:

* bpo-9405: Similar but old (2010) crash caused by SCDynamicStoreCopyProxies in a small Python application using multiprocessing and so using fork
* bpo-27126: "Apple-supplied libsqlite3 on OS X is not fork safe;  can cause crashes"
* "fork() without exec() is dangerous in large programs" article by Evan Jones (2016-August-16): http://www.evanjones.ca/fork-is-dangerous.html -- this article mentions bpo-27126

Ned Deily's advice from bpo-9405: "A quick workaround is to make a [get_proxies()] call from the main process."

IMHO the safest fix is to not run any Python program after fork(). Using use subprocess to use fork() immmediately followed by exec(). It's not safe to execute code after fork(), many functions are not "fork safe". But I know that many applications don't care, since there is also a lot of functions which are fork safe...

----------
nosy: +haypo
title: macOS HighSierra final - Python Crash because of _scproxy -> [macOS] _scproxy.get_proxies() crash -- get_proxies() is not fork-safe?

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Thu Oct 19 08:41:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Oct 2017 12:41:12 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <1508416872.9.0.213398074469.issue31818@psf.upfronthosting.co.za>


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

Confirmation from Apple:

https://developer.apple.com/library/content/technotes/tn2083/_index.html#//apple_ref/doc/uid/DTS10003794-CH1-SUBSECTION52

"""
Many Mac OS X frameworks do not work reliably if you call fork but do not call exec. The only exception is the System framework and, even there, the POSIX standard places severe constraints on what you can do between a fork and an exec.
(...)
Listing 13  Core Foundation complaining about fork-without-exec

The process has forked and you cannot use this CoreFoundation \
functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_\
COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Thu Oct 19 08:41:52 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Oct 2017 12:41:52 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <1508416912.49.0.213398074469.issue31818@psf.upfronthosting.co.za>


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

@Mirko: You can please try to get the Python traceback of the Ansible crash? You may want to try faulthandler: enable it and write its output into a file.
https://faulthandler.readthedocs.io/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Thu Oct 19 08:58:41 2017
From: report at bugs.python.org (F. Lamar)
Date: Thu, 19 Oct 2017 12:58:41 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1508417921.63.0.213398074469.issue31811@psf.upfronthosting.co.za>


F. Lamar <lamar.frankie at gmail.com> added the comment:

I a new contributor. This seems like a simple fix. I'd be happy to work on it. I will submit ar PR on or before 10-22-17

----------
nosy: +F. Lamar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Thu Oct 19 09:32:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Oct 2017 13:32:28 +0000
Subject: [issue31233] socketserver.ThreadingMixIn leaks running threads after
 server_close()
In-Reply-To: <1503073499.39.0.93886151367.issue31233@psf.upfronthosting.co.za>
Message-ID: <1508419948.48.0.213398074469.issue31233@psf.upfronthosting.co.za>


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

The current code leaks memory since it never clears threads which completed. We need a cleanup function similar to ForkingMixIn.collect_children() which is called by handle_timeout() and service_actions().

We can check if a thread is alive: thread.is_alive(), to decide to remove it or not.

Moreover, maybe we should keep a list of weak references?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31233>
_______________________________________

From report at bugs.python.org  Thu Oct 19 09:56:11 2017
From: report at bugs.python.org (Paul G)
Date: Thu, 19 Oct 2017 13:56:11 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508421371.76.0.213398074469.issue31800@psf.upfronthosting.co.za>


Paul G <p.ganssle at gmail.com> added the comment:

This seems very useful to me. I very frequently advise people *against* using dateutil.parser (despite my conflict of interest as maintainer of dateutil) for well-known formats, but the problem frequently comes up of, "what should I do when I have date created by isoformat()?", to which there's no clean satisfying answer other than, "use dateutil.parser even though you know the format."

I think the strptime page that Mario linked to is evidence that the %z directive is *intended* to match against -HH:MM, and so that might be the most "standard" solution.

That said, I somewhat prefer the granularity of the GNU date extensions %z, %:z and %::z, since this allows downstream users to be stricter about what they are willing to accept. I think either approach is defensible, but that *something* should be done soon, preferably for the 3.7 release.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:16:12 2017
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Oct 2017 17:16:12 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <1508433372.02.0.213398074469.issue31818@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Ronald is the expert on this but, from what I understand, I don't think there is any reason to spend time on trying to further analyze this.  This issue has been around since day one of _scproxy and affects all versions of Python on macOS.  There is nothing we can do to fix it, and, after all these years, it isn't likely that Apple is going to change the underlying framework.  What we could do is: (1) better document the restriction; (2) find another way to access the system's network proxy configuration (not likely), or (3) change how we use the System Configuration framework, i.e. either don't call it at all or don't call it by default (but that seems like overfill for an edge case for which there already is a fairly simple workaround).  Ronald, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:25:01 2017
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 19 Oct 2017 17:25:01 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508433901.17.0.213398074469.issue31457@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset ce9e62544571e7ade7186697d5dd065fb4c5243f by ?ukasz Langa in branch 'master':
bpo-31457: Don't omit inner ``process()`` calls with nested LogAdapters (#4044)
https://github.com/python/cpython/commit/ce9e62544571e7ade7186697d5dd065fb4c5243f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:32:12 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Oct 2017 17:32:12 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508434332.98.0.213398074469.issue31457@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4019

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:37:49 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Oct 2017 17:37:49 +0000
Subject: [issue31819] Add sock_recv_into to AbstractEventLoop
Message-ID: <1508434669.81.0.213398074469.issue31819@psf.upfronthosting.co.za>


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

As sock_recv() is already exposed, it is a no-brainer to add sock_recv_into(), allowing finer buffer management when people are willing to handle a socket object.

----------
components: Library (Lib), asyncio
messages: 304623
nosy: giampaolo.rodola, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Add sock_recv_into to AbstractEventLoop
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31819>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:38:43 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Oct 2017 17:38:43 +0000
Subject: [issue31819] Add sock_recv_into to AbstractEventLoop
In-Reply-To: <1508434669.81.0.213398074469.issue31819@psf.upfronthosting.co.za>
Message-ID: <1508434723.47.0.213398074469.issue31819@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4020
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31819>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:39:56 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 17:39:56 +0000
Subject: [issue30457] Allow retrieve the number of waiters pending for most of
 the asyncio lock primitives
In-Reply-To: <1495637305.13.0.0526704297983.issue30457@psf.upfronthosting.co.za>
Message-ID: <1508434796.68.0.213398074469.issue30457@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The nature of the `pending` method is to give to the developer a way to check how many waiters are still pending. This not only helps to make this code more explicit also other pieces of code that might need access to the length of the waiters.

This also is a perfect way to introduce races in your code.  I'm going to reject this, sorry.  I've demonstrated that it's possible to do what you wanted to do without adding new functionality.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30457>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:48:16 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 17:48:16 +0000
Subject: [issue31452] asyncio.gather does not cancel tasks if one fails
In-Reply-To: <1505314417.04.0.216091950997.issue31452@psf.upfronthosting.co.za>
Message-ID: <1508435296.1.0.213398074469.issue31452@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'm going to reject this issue as it's not backwards compatible.  I'll work on adding a new TaskGroup primitive in the next couple of days that would address this problem.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31452>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:49:59 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 17:49:59 +0000
Subject: [issue31632] Asyncio: SSL transport does not support set_protocol()
In-Reply-To: <1506675573.99.0.213398074469.issue31632@psf.upfronthosting.co.za>
Message-ID: <1508435399.92.0.213398074469.issue31632@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ea2ef5d0ca869d4550820ed53bdf56013dbb9546 by Yury Selivanov (jlacoline) in branch 'master':
bpo-31632: fix set_protocol() in _SSLProtocolTransport (#3817) (#3817)
https://github.com/python/cpython/commit/ea2ef5d0ca869d4550820ed53bdf56013dbb9546


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31632>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:50:09 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Oct 2017 17:50:09 +0000
Subject: [issue31632] Asyncio: SSL transport does not support set_protocol()
In-Reply-To: <1506675573.99.0.213398074469.issue31632@psf.upfronthosting.co.za>
Message-ID: <1508435409.09.0.213398074469.issue31632@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31632>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:50:44 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 17:50:44 +0000
Subject: [issue31632] Asyncio: SSL transport does not support set_protocol()
In-Reply-To: <1506675573.99.0.213398074469.issue31632@psf.upfronthosting.co.za>
Message-ID: <1508435444.82.0.213398074469.issue31632@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Lo?c, thank you for the contribution!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31632>
_______________________________________

From report at bugs.python.org  Thu Oct 19 13:57:14 2017
From: report at bugs.python.org (Zirak)
Date: Thu, 19 Oct 2017 17:57:14 +0000
Subject: [issue31820] Calling email.message.set_payload twice produces an
 invalid eml
Message-ID: <1508435834.65.0.213398074469.issue31820@psf.upfronthosting.co.za>


New submission from Zirak <zirakertan at gmail.com>:

Example:

In [52]: import email.message

In [53]: m = email.message.Message()

In [54]: m.set_payload('abc', 'utf8')

In [55]: m.get_payload() # correctly encoded
Out[55]: 'YWJj\n'

In [56]: m.set_payload('abc', 'utf8')

In [57]: m.get_payload() # no more encoding?
Out[57]: 'abc'

In [58]: m.get_payload(decode=True) # wut?
Out[58]: b'i\xb7'

In [59]: print(str(m))
MIME-Version: 1.0
Content-Type: text/plain; charset="utf8"
Content-Transfer-Encoding: base64

abc


While the first `set_payload` correctly encodes and sets the message's
Content-Transfer-Encoding, the second call doesn't properly encode the
payload according to its existing Content-Transfer-Encoding.
Tested on 3.6, 3.5 and 2.7.

`email.message.set_payload` does not directly encode the payload,
instead `email.message.set_charset` does, around line 353:
https://github.com/python/cpython/blob/b067c8fdd1e205bd0411417b6d5e4b832c3773fc/Lib/email/message.py#L353-L368

In both invocations of `set_payload`, the payload is not encoded
according to the encoding. On the first invocation, the `CTE` header
is correctly set according to `charset.get_body_encoding` (#354 and
#368) and the payload is encoded (#356 or #367, the latter in this
case).

On the second invocation, the `CTE` header is already set, so the
payload is never encoded.

This is especially dangerous when passing `decode=True` to
`get_payload` after the 2nd `set_payload`, as that may throw an error
in some cases (trying to base64 decode a string which makes no sense
to it. that's how I arrived on this bug, but I can't for the life of
me replicate an exception).

This is a bit finicky to fix. If we change `set_charset` to always
encode the current payload, we risk double-encoding when `set_charset`
is not called through `set_payload`. However if `set_charset` tries to
decode the payload, it will produce incorrect results when *it is*
called through `set_payload`. urgh.

We can move the actual encoding code away from `set_charset`, either
into `set_payload` or a third function, but that'll break any code
calling `set_payload` without a charset and then calling
`set_charset`. urgh.

One possible solution is for both `set_charset` and `set_payload` to
call a third function, e.g. `_encode_payload`. Perhaps something like
(pseudocode):


def set_payload(self, payload, charset):
    # ...
    if 'Content-Transfer-Encoding' in self:
        self._payload = self._encode_payload(payload)
    self.set_charset(charset)
    # ...

def set_charset(self, charset):
    # ...
    if 'Content-Transfer-Encoding' not in self:
        self._payload = self._encode_payload()
        self.add_header(...)

def _encode_payload(self, payload):
    # code in lines 353-366



This way, `set_charset` handles the cases where CTE was never defined,
and `set_payload` makes sure to encode the payload when a CTE is
present. It may work, but something about this gives me unrest. For
example, if you `set_charset` once and it encodes your payload as
base64, and you `set_charset` again with a charset whose
`get_body_encoding` returns qp, the payload would still be base64 even
though it *should be* qp. urgh.

Is this a big enough concern? Is there a superior approach I'm
missing?

Thanks in advance!

----------
components: email
messages: 304628
nosy: Zirak Ertan, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Calling email.message.set_payload twice produces an invalid eml
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31820>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:05:30 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 18:05:30 +0000
Subject: [issue31819] Add sock_recv_into to AbstractEventLoop
In-Reply-To: <1508434669.81.0.213398074469.issue31819@psf.upfronthosting.co.za>
Message-ID: <1508436330.27.0.213398074469.issue31819@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'm going to approve this unless there are any objections.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31819>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:11:51 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 19 Oct 2017 18:11:51 +0000
Subject: [issue31457] LoggerAdapter objects cannot be nested
In-Reply-To: <1505333712.03.0.134308685605.issue31457@psf.upfronthosting.co.za>
Message-ID: <1508436711.54.0.213398074469.issue31457@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 4d9a8f22999de489ede9216ff983d4359d837760 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-31457: Don't omit inner ``process()`` calls with nested LogAdapters (GH-4044) (GH-4050)
https://github.com/python/cpython/commit/4d9a8f22999de489ede9216ff983d4359d837760


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31457>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:12:46 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 18:12:46 +0000
Subject: [issue31632] Asyncio: SSL transport does not support set_protocol()
In-Reply-To: <1506675573.99.0.213398074469.issue31632@psf.upfronthosting.co.za>
Message-ID: <1508436766.55.0.213398074469.issue31632@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 9c23b173b823b5e6da01d85c570c7ae2ab07b38b by Yury Selivanov (Miss Islington (bot)) in branch '3.6':
bpo-31632: fix set_protocol() in _SSLProtocolTransport (GH-3817) (GH-3817) (#4052)
https://github.com/python/cpython/commit/9c23b173b823b5e6da01d85c570c7ae2ab07b38b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31632>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:25:40 2017
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 19 Oct 2017 18:25:40 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508437540.49.0.213398074469.issue31810@psf.upfronthosting.co.za>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hi Haypo,

I'd like to work on a patch for this issue.

Can you please guide me how the tests are configured for buildbots?

----------
nosy: +CuriousLearner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:28:45 2017
From: report at bugs.python.org (Tim Peters)
Date: Thu, 19 Oct 2017 18:28:45 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508437725.21.0.213398074469.issue31815@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

Segfaults are different:  they usually expose an error in CPython's implementation.  We don't prioritize them because the user may have to restart their program (who cares? <0.5 wink>), but because they demonstrate the language implementation is accessing memory wildly.  That in turn can result in anything, from arbitrarily wrong program results, through file corruption, to massive security holes.  It's far more a "correctness" than a "usability" concern.

If a user provokes a segfault by (ab)using low-level facilities (say, ctypes), we don't care - that's on them.  But most segfaults have pointed to legitimate corner-case errors in CPython itself.

There's no correctness issue in whether iterators are always interruptible - it doesn't merit the same concern.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:32:46 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Oct 2017 18:32:46 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508437540.49.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZF_TOMgQ5Ys_fX0DzpXVU2LtYAaCSuGC8-hCzVWRkRfA@mail.gmail.com>


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

Sanyam: please first try to write a change for Travis CI: modify
.travis.yml, create a PR and check if it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:44:49 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Oct 2017 18:44:49 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508433372.02.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYuZmhUarj1ywsEpEa_0WFO=ZrotN4MOSo0p=Q1BOcFAw@mail.gmail.com>


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

Another workaround is to call get_proxies() in a fresh subprocess, and use
a pipe to retrieve the result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:49:03 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Oct 2017 18:49:03 +0000
Subject: [issue31821] pause_reading() doesn't work from connection_made()
Message-ID: <1508438943.14.0.213398074469.issue31821@psf.upfronthosting.co.za>


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

At least in SelectorEventLoop, as add_reader() is called inconditionally after connection_made() returns.

----------
components: Library (Lib), asyncio
messages: 304636
nosy: giampaolo.rodola, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: pause_reading() doesn't work from connection_made()
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31821>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:53:05 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Oct 2017 18:53:05 +0000
Subject: [issue31821] pause_reading() doesn't work from connection_made()
In-Reply-To: <1508438943.14.0.213398074469.issue31821@psf.upfronthosting.co.za>
Message-ID: <1508439185.55.0.213398074469.issue31821@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4022
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31821>
_______________________________________

From report at bugs.python.org  Thu Oct 19 14:54:33 2017
From: report at bugs.python.org (Allen Li)
Date: Thu, 19 Oct 2017 18:54:33 +0000
Subject: [issue31822] Document that urllib.parse.{Defrag, Split,
 Parse}Result are namedtuples
Message-ID: <1508439273.05.0.213398074469.issue31822@psf.upfronthosting.co.za>


New submission from Allen Li <vianchielfaura at gmail.com>:

It would be useful to document that urllib.parse.{Defrag,Split,Parse}Result are namedtuples, and make that API officially public if it was not otherwise.

These classes are implemented as namedtuples in Python 2 and 3, and I am not aware of a reason that that would need to change in the future.

In particular, the namedtuple _replace() method is very useful for modifying parts of a URL, a common use case.

 u = urllib.parse.urlsplit(some_url)
 u = u._replace(netloc=other_netloc)
 urllib.parse.urlunsplit(u)

 # Alternatives not depending on namedtuple API
 parts = list(u)
 parts[1] = other_netloc  # Using a magic index
 urllib.parse.urlunsplit(u)

 u = urllib.parse.SplitResult(  # Very ugly
     scheme=u.scheme,
     netloc=other_netloc,
     path=u.path,
     query=u.query,
     fragment=u.fragment)

----------
assignee: docs at python
components: Documentation
messages: 304637
nosy: Allen Li, docs at python
priority: normal
severity: normal
status: open
title: Document that urllib.parse.{Defrag,Split,Parse}Result are namedtuples
type: enhancement
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Thu Oct 19 15:15:41 2017
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 19 Oct 2017 19:15:41 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508440541.59.0.213398074469.issue31810@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
keywords: +patch
pull_requests: +4023
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Thu Oct 19 15:24:20 2017
From: report at bugs.python.org (Mike Frysinger)
Date: Thu, 19 Oct 2017 19:24:20 +0000
Subject: [issue31822] Document that urllib.parse.{Defrag, Split,
 Parse}Result are namedtuples
In-Reply-To: <1508439273.05.0.213398074469.issue31822@psf.upfronthosting.co.za>
Message-ID: <1508441060.2.0.213398074469.issue31822@psf.upfronthosting.co.za>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

specifically, the docs for these classes:
https://docs.python.org/2/library/urlparse.html#results-of-urlparse-and-urlsplit
https://docs.python.org/3/library/urllib.parse.html#urlparse-result-object

> The result objects from the urlparse() and urlsplit() functions are subclasses
> of the tuple type. These subclasses add the attributes described in those
> functions, as well as provide an additional method:
> ...
> class urlparse.SplitResult(scheme, netloc, path, query, fragment)
>   Concrete class for urlsplit() results.

changing "subclasses of the tuple type" to "subclasses of collections.namedtuples" would be great.  also adding hints to use _replace to update values would be great :).

----------
nosy: +vapier

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Thu Oct 19 15:42:38 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 Oct 2017 19:42:38 +0000
Subject: [issue31819] Add sock_recv_into to AbstractEventLoop
In-Reply-To: <1508436330.27.0.213398074469.issue31819@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJL2ubNDtEpC6Gm4o+aj6hV-KPJn=rhcVHbje7Vb83DizQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

SGTM.

On Oct 19, 2017 11:05 AM, "Yury Selivanov" <report at bugs.python.org> wrote:

>
> Yury Selivanov <yselivanov at gmail.com> added the comment:
>
> I'm going to approve this unless there are any objections.
>
> ----------
> nosy: +gvanrossum
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31819>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31819>
_______________________________________

From report at bugs.python.org  Thu Oct 19 15:46:42 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 19:46:42 +0000
Subject: [issue31819] Add sock_recv_into to AbstractEventLoop
In-Reply-To: <1508434669.81.0.213398074469.issue31819@psf.upfronthosting.co.za>
Message-ID: <1508442402.44.0.213398074469.issue31819@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 525f40d231aba2c004619fc7a5207171ed65b0cb by Yury Selivanov (Antoine Pitrou) in branch 'master':
bpo-31819: Add AbstractEventLoop.sock_recv_into() (#4051)
https://github.com/python/cpython/commit/525f40d231aba2c004619fc7a5207171ed65b0cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31819>
_______________________________________

From report at bugs.python.org  Thu Oct 19 15:47:17 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 19 Oct 2017 19:47:17 +0000
Subject: [issue31819] Add sock_recv_into to AbstractEventLoop
In-Reply-To: <1508434669.81.0.213398074469.issue31819@psf.upfronthosting.co.za>
Message-ID: <1508442437.44.0.213398074469.issue31819@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Merged. Thank you, Antoine!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31819>
_______________________________________

From report at bugs.python.org  Thu Oct 19 16:34:16 2017
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdC10Lkg0JDQstC10YDRh9C10L3QutC+?=)
Date: Thu, 19 Oct 2017 20:34:16 +0000
Subject: [issue31823] Opaque default value for close_fds argument in
 Popen.__init__
Message-ID: <1508445256.4.0.213398074469.issue31823@psf.upfronthosting.co.za>


New submission from ??????? ????????? <lex.aver at gmail.com>:

[11:30:03 ~]$ python
Python 3.6.1 |Anaconda 4.4.0 (x86_64)| (default, May 11 2017, 13:04:09)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> help(subprocess.Popen.__init__)
Help on function __init__ in module subprocess:

__init__(self, args, bufsize=-1, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=<object object at 0x10df99150>, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=(), *, encoding=None, errors=None)
    Create new Popen instance.

----------
components: Library (Lib)
messages: 304642
nosy: ??????? ?????????
priority: normal
severity: normal
status: open
title: Opaque default value for close_fds argument in Popen.__init__
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31823>
_______________________________________

From report at bugs.python.org  Thu Oct 19 17:55:03 2017
From: report at bugs.python.org (Zirak)
Date: Thu, 19 Oct 2017 21:55:03 +0000
Subject: [issue31820] Calling email.message.set_payload twice produces an
 invalid eml
In-Reply-To: <1508435834.65.0.213398074469.issue31820@psf.upfronthosting.co.za>
Message-ID: <1508450103.29.0.213398074469.issue31820@psf.upfronthosting.co.za>


Zirak <zirakertan at gmail.com> added the comment:

On irc, bitmancer suggested that this problem is already solved by the
email.message.EmailMessage class, as it is:


In [119]: m = email.message.EmailMessage()

In [120]: m.set_content('abc', 'utf8', cte='base64')

In [121]: m.get_payload()
Out[121]: 'YWJjCg==\n'

In [122]: m.set_content('abc', 'utf8', cte='base64')

In [123]: m.get_payload()
Out[123]: 'YWJjCg==\n'

In [124]: m.get_payload(decode=True)
Out[124]: b'abc\n'

In [125]: print(m)
MIME-Version: 1.0
Content-Type: text/utf8; charset="utf-8"
Content-Transfer-Encoding: base64

YWJjCg==


Because this isn't a critical bug and `email.message.Message` is quite
deprecated, and this is solved by a newer API, this bug may not need
addressing.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31820>
_______________________________________

From report at bugs.python.org  Thu Oct 19 18:15:10 2017
From: report at bugs.python.org (Mario Corchero)
Date: Thu, 19 Oct 2017 22:15:10 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508451310.8.0.213398074469.issue31800@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

As a note

Seems support for the ":" was added in 2015 for glibc:
http://code.metager.de/source/xref/gnu/glibc/time/strptime_l.c#765

Commit e952e1df

Before that, it basically just ignores the minutes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Thu Oct 19 18:24:09 2017
From: report at bugs.python.org (Mario Corchero)
Date: Thu, 19 Oct 2017 22:24:09 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508451849.48.0.213398074469.issue31800@psf.upfronthosting.co.za>


Mario Corchero <mariocj89 at gmail.com> added the comment:

I have a patch to add 'Z' support as well if we are interested in making it the same as it glibc does. (as it supports it as well)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Thu Oct 19 19:17:42 2017
From: report at bugs.python.org (Peter Lovett)
Date: Thu, 19 Oct 2017 23:17:42 +0000
Subject: [issue31824] Missing default argument detail in documentation of
 StreamReaderWriter
Message-ID: <1508455062.42.0.213398074469.issue31824@psf.upfronthosting.co.za>


New submission from Peter Lovett <pacqa100 at yahoo.com.au>:

Documentation of StreamReaderWriter at
https://docs.python.org/3/library/codecs.html#codecs.StreamReaderWriter
section 7.2.1.4.3 is missing the default value on the errors argument.

Should change from:
class codecs.StreamReaderWriter(stream, Reader, Writer, errors)
to be:
class codecs.StreamReaderWriter(stream, Reader, Writer, errors='strict')

----------
assignee: docs at python
components: Documentation
messages: 304646
nosy: PeterLovett, docs at python
priority: normal
severity: normal
status: open
title: Missing default argument detail in documentation of StreamReaderWriter
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31824>
_______________________________________

From report at bugs.python.org  Thu Oct 19 20:27:58 2017
From: report at bugs.python.org (Janko Krstic)
Date: Fri, 20 Oct 2017 00:27:58 +0000
Subject: [issue31163] Return destination path in Path.rename and Path.replace
In-Reply-To: <1502292744.48.0.627996317333.issue31163@psf.upfronthosting.co.za>
Message-ID: <1508459278.37.0.213398074469.issue31163@psf.upfronthosting.co.za>


Change by Janko Krstic <keichiri at protonmail.com>:


----------
keywords: +patch
pull_requests: +4024
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31163>
_______________________________________

From report at bugs.python.org  Thu Oct 19 22:22:14 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 02:22:14 +0000
Subject: [issue31761] Failures and crashes when running tests by import.
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1508466134.51.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

I am re-opening because there is a bug, a conflict between doc and code comment and actual behavior, and one which has nothing to do with IDLE.  The question is whether to fix it or to delete the invitation to invoke the bug.

The reason the devguide gives an alternative for running tests is so that someone with only installed Python and no command line could still test their installation and even contribute a patch on the tracker.

On 2000-08-23, Tim Peters add the following comment to test.autotest:
# This should be equivalent to running regrtest.py from the cmdline.
# It can be especially handy if you're in an interactive shell, e.g.,
# from test import autotest.

The autotest code was later copied into test.__main__, and both are now:
  from test.libregrtest import main
  main()
So 'from test import __main__' is the same as importing autotest, and should be the same as importing and running libregrtest

To test the equivalence in the setting where either import might be useful, I opened both python and IDLE from the 3.7.0a2 Windows start icons and imported autotest.  The test deterministicly crashes after test_marshal.  I call the stoppage a crash because wrapping the import in try: ... except BaseException has no effect.  The Python console just vanishes.  IDLE restarts.
...
0:05:51 [207/407/5] test_marshal

=============================== RESTART: Shell =========================
>>>

So the claimed equivalence in worse than just not true.  There were, I believe, 3 failures in the Python console.  The extra 2 in IDLE are due to the #25588 fix guarding against sys.stderr being None is needed in a couple of other places.

In any case, either running tests by importing should be made to work (again, presuming it once did) or deprecated and autotest removed.

----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open
title: regrtest: faulthandler.enable() fails with io.UnsupportedOperation: fileno when run from IDLE -> Failures and crashes when running tests by import.
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Fri Oct 20 03:43:10 2017
From: report at bugs.python.org (Tal Einat)
Date: Fri, 20 Oct 2017 07:43:10 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508485390.74.0.213398074469.issue31810@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Fri Oct 20 03:52:44 2017
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 20 Oct 2017 07:52:44 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <1508485964.36.0.213398074469.issue31818@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Calling get_proxies() in a subprocess would also work, although I'd then prefer to use a small daemon proces to avoid the startup cost of a new process for every call to _scproxy functions.

There is a conflict between two goals w.r.t. the macOS port:

1) Integrate nicely with the platform

2) Be like other unixy platforms

The former requires the use of Apple specific APIs, like those used in _scproxy, but those cause problems when using fork without calling exec.

The latter is technically an issue for all processing using threads on POSIX systems (see <http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html>), AFAIK users get bitten by this more on macOS because Apple appears to use threading in their implementation (making processes multi-threaded without explicitly using threading in user code), and because Apple explicitly checks for the "fork without exec" case and crashes the child proces.

This can of course also be seen as a qualify of implementation issue on macOS, as in "Apple can't be bothered to do the work to support this use case" ;-/

Anyways: As Ned writes this is unlikely to change on Apple's side and we have to life with that.

There's three options going forward:

1) Remove _scproxy

I'm -1 on that because I'm in favour of having good platform integration, Python's URL fetching APIs should transparently use the system proxy config configuration.

2) Document this problem and move on

3) Find a workaround (such as calling the APIs used by _scproxy in a clean supprocess).

The 3th option is probably the most useful in the long run, but requires someone willing to do the work.  I'm in principle willing to do the work, but haven't had enough free time to work on CPython for quite a while now (which saddens me, but that's off topic).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Fri Oct 20 04:52:20 2017
From: report at bugs.python.org (Quentin Dawans)
Date: Fri, 20 Oct 2017 08:52:20 +0000
Subject: [issue31203] socket.IP_PKTINFO is missing from python
In-Reply-To: <1502722784.42.0.622750235869.issue31203@psf.upfronthosting.co.za>
Message-ID: <1508489540.15.0.213398074469.issue31203@psf.upfronthosting.co.za>


Change by Quentin Dawans <contact at quentindawans.com>:


----------
nosy: +qdawans

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31203>
_______________________________________

From report at bugs.python.org  Fri Oct 20 04:59:33 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 08:59:33 +0000
Subject: [issue31818] [macOS] _scproxy.get_proxies() crash -- get_proxies() is
 not fork-safe?
In-Reply-To: <1508409035.64.0.213398074469.issue31818@psf.upfronthosting.co.za>
Message-ID: <1508489973.52.0.213398074469.issue31818@psf.upfronthosting.co.za>


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

> 3) Find a workaround (such as calling the APIs used by _scproxy in a clean supprocess).

I dislike the idea of *always* spawning a child process, I prefer to leave it as it is, but add a recipe in the doc, or add a new helper function doing that.

Spawning a subprocess can have side effects as well, whereas the subprocess is only need if you call the function after forking which is not the most common pattern in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31818>
_______________________________________

From report at bugs.python.org  Fri Oct 20 05:04:12 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 20 Oct 2017 09:04:12 +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: <1508490252.21.0.213398074469.issue17799@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +4025
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Fri Oct 20 05:29:33 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Oct 2017 09:29:33 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1508491773.52.0.213398074469.issue25658@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Would it be possible to define Py_tss_NEEDS_INIT as a constant variable instead of a static initialiser? That would enable its use also for non-static initialisations.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Oct 20 05:58:20 2017
From: report at bugs.python.org (Sebastian Kacprzak)
Date: Fri, 20 Oct 2017 09:58:20 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
Message-ID: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>


New submission from Sebastian Kacprzak <nait at naitbit.com>:

In Python 3.5 and earlier (tested 3.5.3 and 2.7.13)
b'\\\xfa'.decode('unicode-escape', errors='ignore')
did return '\\?'

but in Python 3.6 it raises 
OverflowError: decoding with 'unicode-escape' codec failed (OverflowError: character argument not in range(0x110000))


Python 3.6.1 (default, Sep  7 2017, 16:36:03) 
[GCC 6.3.0 20170406] on linux

----------
messages: 304651
nosy: nait
priority: normal
severity: normal
status: open
title: bytes decode raises OverflowError desipte errors='ignore'
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 06:21:29 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 10:21:29 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508494889.01.0.213398074469.issue31810@psf.upfronthosting.co.za>


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


----------
pull_requests: +4026

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Fri Oct 20 06:51:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 10:51:03 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
In-Reply-To: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>
Message-ID: <1508496663.66.0.213398074469.issue31825@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
components: +Interpreter Core, Unicode
nosy: +eric.smith, ezio.melotti, haypo, serhiy.storchaka
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 07:09:08 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Oct 2017 11:09:08 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1508497748.17.0.213398074469.issue25658@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Stefan: I'd expect so, but that's best covered by a new RFE and an associated PR (I'm not sure what you mean from the text description, but I assume it will be obvious as C code)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Oct 20 07:10:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 11:10:59 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
In-Reply-To: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>
Message-ID: <1508497859.79.0.213398074469.issue31825@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4027
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 08:35:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 12:35:25 +0000
Subject: [issue31761] Failures and crashes when running tests by import in IDLE
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1508502925.95.0.213398074469.issue31761@psf.upfronthosting.co.za>


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


----------
title: Failures and crashes when running tests by import. -> Failures and crashes when running tests by import in IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Fri Oct 20 09:04:35 2017
From: report at bugs.python.org (Albert Zeyer)
Date: Fri, 20 Oct 2017 13:04:35 +0000
Subject: [issue31814] subprocess_fork_exec more stable with vfork
In-Reply-To: <1508343864.17.0.213398074469.issue31814@psf.upfronthosting.co.za>
Message-ID: <1508504675.31.0.213398074469.issue31814@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

Here is some more background for a case where this occurs:
https://stackoverflow.com/questions/46849566/multi-threaded-openblas-and-spawning-subprocesses

My proposal here would fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31814>
_______________________________________

From report at bugs.python.org  Fri Oct 20 09:21:04 2017
From: report at bugs.python.org (Jakub Mateusz Dzik)
Date: Fri, 20 Oct 2017 13:21:04 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
Message-ID: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>


New submission from Jakub Mateusz Dzik <bugs.python.org20171020 at amix.org.pl>:

Several modules of the standard library (at least `re` and `csv`) have `__version__` strings.

The string is the same for Python 2.7-3.6:

    >>> import re, csv; print(re.__version__, csv.__version__)
    2.2.1 1.0

while documentation indicates changes in the modules.

Semantic versioning (recommended by PEP 440) suggests that at least minor version should change in such case.

I suspect it to be a "code fossil" which may be removed according to PEP 396.

----------
components: Library (Lib)
messages: 304654
nosy: abukaj
priority: normal
severity: normal
status: open
title: Misleading __version__ attribute of modules in standard library
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:03:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 14:03:40 +0000
Subject: [issue31827] Remove os.stat_float_times()
Message-ID: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>


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

os.stat_float_times() was introduced in Python 2.3 to get file modification times with sub-second resolution. The default remains to get time as seconds (integer). See commit f607bdaa77475ec8c94614414dc2cecf8fd1ca0a.

The function was introduced to get a smooth transition to time as floating point number, to keep the backward compatibility with Python 2.2.

In Python 2.5, os.stat() returns time as float by default: commit fe33d0ba87f5468b50f939724b303969711f3be5.

Python 2.5 was released 11 years ago. I consider that people had enough time to migrate their code to float time :-)

I modified os.stat_float_times() to emit a DeprecationWarning in Python 3.1: commit 034d0aa2171688c40cee1a723ddcdb85bbce31e8 (bpo-14711).

----------
messages: 304655
nosy: haypo
priority: normal
severity: normal
status: open
title: Remove os.stat_float_times()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:08:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 14:08:21 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
In-Reply-To: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>
Message-ID: <1508508501.64.0.213398074469.issue31825@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 56cb465cc93dcb35aaf7266ca3dbe2dcff1fac5f by Serhiy Storchaka in branch 'master':
bpo-31825: Fixed OverflowError in the 'unicode-escape' codec (#4058)
https://github.com/python/cpython/commit/56cb465cc93dcb35aaf7266ca3dbe2dcff1fac5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:08:29 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Oct 2017 14:08:29 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
In-Reply-To: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>
Message-ID: <1508508509.05.0.213398074469.issue31825@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4028

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:27:18 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Oct 2017 14:27:18 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1508509638.04.0.213398074469.issue25658@psf.upfronthosting.co.za>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
pull_requests: +4029

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:30:12 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Oct 2017 14:30:12 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1508509812.56.0.213398074469.issue25658@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

It seems that there's a simpler way that uses a cast on the literal. I added a pull request. Looks simple enough to not merit its own ticket, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:41:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 14:41:31 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
In-Reply-To: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>
Message-ID: <1508510491.4.0.213398074469.issue31825@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1e78ed6825701029aa45a68f9e62dd3bb8d4e928 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31825: Fixed OverflowError in the 'unicode-escape' codec (GH-4058) (#4059)
https://github.com/python/cpython/commit/1e78ed6825701029aa45a68f9e62dd3bb8d4e928


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:42:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 14:42:35 +0000
Subject: [issue31825] bytes decode raises OverflowError desipte errors='ignore'
In-Reply-To: <1508493500.2.0.213398074469.issue31825@psf.upfronthosting.co.za>
Message-ID: <1508510555.65.0.213398074469.issue31825@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report Sebastian.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:51:31 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 14:51:31 +0000
Subject: [issue31827] Remove os.stat_float_times()
In-Reply-To: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>
Message-ID: <1508511091.9.0.213398074469.issue31827@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4030
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Fri Oct 20 10:52:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 14:52:14 +0000
Subject: [issue31827] Remove os.stat_float_times()
In-Reply-To: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>
Message-ID: <1508511134.03.0.213398074469.issue31827@psf.upfronthosting.co.za>


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

Attached PR 4061 removes os.stat_float_times().

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Fri Oct 20 12:07:56 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Oct 2017 16:07:56 +0000
Subject: [issue31828] Support Py_tss_NEEDS_INIT outside of static
 initialisation
Message-ID: <1508515676.46.0.213398074469.issue31828@psf.upfronthosting.co.za>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

Following up on issue 25658, it was found that the current definition of Py_tss_NEEDS_INIT restricts its use to initialisers in C and cannot be used for arbitrary assignments. It is currently declared as follows:

    #define Py_tss_NEEDS_INIT   {0}

which results in a C compiler error for assignments like "x = Py_tss_NEEDS_INIT".

I proposed to change this to

    #define Py_tss_NEEDS_INIT   ((Py_tss_t) {0})

in compliance with GCC and C99, but that fails to compile in MSVC and probably other old C++-ish compilers.

I'm not sure how to improve this declaration, but given that it's a public header file, restricting its applicability seems really unfortunate.

----------
components: Extension Modules, Interpreter Core
messages: 304661
nosy: masamoto, ncoghlan, scoder
priority: normal
pull_requests: 4031
severity: normal
status: open
title: Support Py_tss_NEEDS_INIT outside of static initialisation
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31828>
_______________________________________

From report at bugs.python.org  Fri Oct 20 12:07:59 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 20 Oct 2017 16:07:59 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1508515679.21.0.213398074469.issue16737@psf.upfronthosting.co.za>


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

> All of the differences in semantics make total sense when you realize `-m pkg` is really conceptually shorthand for `import pkg.__main__` (w/ the appropriate __name__ flourishes).
> So instead of selling `-m` as a way to run a module/package as a script, I say we change the message/documentation to say it does an import with __name__ changed and make specifying a script as the weird reading-a-file-directly thing.

I agree the explanation makes sense. But is that the design we want?

In my opinion, the most meaningful purpose of `-m` is its ability to run a module/package as a script. I've rarely seen it used as a convenience for executing a Python file, but I've seen it used extensively for providing entry to the canonical behavior for a library:

- pip: python -m pip
- pytest: python -m pytest
- setuptools: python -m easy_install
- virtualenv: python -m virtualenv

[rwt](https://pypi.org/project/rwt) takes advantage of this mechanism as the primary way to invoke a module (because scripts don't provide an API at the Python interpreter level):

    $ rwt -q paver -- -m paver --version
    Paver 1.2.4 

I began using this functionality extensively when on Windows using pylauncher, as it was the only reliable mechanism to invoke behavior with a desired Python interpreter:

    PS> py -3.3 -m pip

If the semantics of -m are by design and need to be retained, it seems to me there's a strong argument for a new parameter, one which works much as -m, but which has the semantics of launching a script (as much as possible). Consider "python -r module" (for Run). Alternatively, Python could distribute a new runner executable whose purpose is specifically for running modules. Consider "pyrun module".

I don't think it will be sufficient to simply add a --nopath0 option, as that would impose that usage on the user... and `python -m modulename` is just at the limit of what syntax I think I can reasonably expect my users to bear for launching a script.

My preference would be to alter the semantics of `-m` with the explicit intention to align it with script launch behavior, or to provide a new concise mechanism for achieving this goal.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Fri Oct 20 12:09:32 2017
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Oct 2017 16:09:32 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1508515772.01.0.213398074469.issue25658@psf.upfronthosting.co.za>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Seems like this isn't trivial, so I created a new ticket for this. See issue 31828.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:05:24 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 17:05:24 +0000
Subject: [issue31782] Add a timeout to multiprocessing's Pool.join
In-Reply-To: <1507922622.85.0.213398074469.issue31782@psf.upfronthosting.co.za>
Message-ID: <1508519124.19.0.213398074469.issue31782@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +davin, pitrou
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31782>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:06:20 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 17:06:20 +0000
Subject: [issue31783] Race condition in ThreadPoolExecutor when scheduling new
 jobs while the interpreter shuts down
In-Reply-To: <1507930035.71.0.213398074469.issue31783@psf.upfronthosting.co.za>
Message-ID: <1508519180.16.0.213398074469.issue31783@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31783>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:08:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 17:08:11 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508519291.47.0.213398074469.issue31803@psf.upfronthosting.co.za>


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


----------
pull_requests: +4032
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:09:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 17:09:10 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508519350.01.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

I wrote the PR 4062 which removes time.clock() implementation: time.clock becomes an alias to time.perf_counter.

haypo at selma$ ./python
Python 3.7.0a2+ (heads/clock-dirty:16b6a3033e, Oct 20 2017, 18:55:58) 
>>> import time
>>> time.clock is time.perf_counter
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:12:31 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 17:12:31 +0000
Subject: [issue31790] double free or corruption (while using smem)
In-Reply-To: <1508047232.57.0.213398074469.issue31790@psf.upfronthosting.co.za>
Message-ID: <1508519551.03.0.213398074469.issue31790@psf.upfronthosting.co.za>


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

The error log is not present.  Try uploading again.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31790>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:34:29 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 17:34:29 +0000
Subject: [issue31793] Allow to specialize smart quotes in documentation
 translations
In-Reply-To: <1508060988.99.0.213398074469.issue31793@psf.upfronthosting.co.za>
Message-ID: <1508520869.52.0.213398074469.issue31793@psf.upfronthosting.co.za>


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

Patch is trivial two lines but needs review and merge from someone familiar with Sphinx stuff.

[?ric, https://docs.python.org/devguide/experts.html contains the invalid Eric.Araujo]

----------
nosy: +ezio.melotti, merwok, terry.reedy, willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31793>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:41:29 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 17:41:29 +0000
Subject: [issue31829] Portability issues with pickle
Message-ID: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

After reading numerous pickle-related issues on GitHab, I have found that the most common issue with pickle in Python 2 is using it with files opened with text mode.

    with open(file_name, "w") as f:
        pickle.dump(data, f)

Initially pickle was a text protocol. But since implementing more efficient binary opcodes it is a binary protocol. Even the default protocol 0 is not completely text-safe. If save and load data containing Unicode strings with "text" protocol 0 using different text/binary modes or using text mode on different platforms, you can get an error or incorrect data.

I propose to add more defensive checks for pickle.

1. When save a pickle with protocol 0 (default) to a file opened in text mode (default) emit a Py3k warning.

2. When save a pickle with binary protocols (must be specified explicitly) to a file opened in text mode raise a ValueError on Windows and Mac Classic (resulting data is likely corrupted) and emit a warning on Unix and Linux. What the type of of warnings is more appropriate? DeprecationWarning, DeprecationWarning in py3k mode, RuntimeWarning, or UnicodeWarning?

3. Escape \r and \x1a (end-of-file in MS DOS) when pickle Unicode strings with protocol 0.

4. Detect the most common errors (e.g. module name ending with \r when load on Linux a pickle saved with text mode on Windows) and raise more informative error message.

5. Emit a warning when load an Unicode string ending with \r. This is likely an error (if the pickle was saved with text mode on Windows), but  this can a correct data if the saved Unicode string actually did end with \r. This is the most dubious proposition. On one hand, it is better to warn than silently return an incorrect result. On other hand, the correct result shouldn't provoke a warning.

----------
components: Library (Lib)
messages: 304667
nosy: alexandre.vassalotti, benjamin.peterson, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Portability issues with pickle
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31829>
_______________________________________

From report at bugs.python.org  Fri Oct 20 13:46:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 17:46:48 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508521608.25.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This will break a code that depends on the current behavior on non-Windows platforms. And this will contradict the expectation of non-Windows programmers. If change the behavior of clock() on non-Windows platforms, it should be done only after the period of emitting FutureWarning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:41:48 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:41:48 +0000
Subject: [issue31798] `site.abs__file__` fails for modules where `__file__`
 cannot be modified
In-Reply-To: <1508151616.4.0.213398074469.issue31798@psf.upfronthosting.co.za>
Message-ID: <1508524908.53.0.213398074469.issue31798@psf.upfronthosting.co.za>


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

2.7 site module has

def abs__file__():
    """Set all module' __file__ attribute to an absolute path"""
    for m in sys.modules.values():
        if hasattr(m, '__loader__'):
            continue   # don't mess with a PEP 302-supplied __file__
        try:
            m.__file__ = os.path.abspath(m.__file__)
        except (AttributeError, OSError):
            pass

This code assumes that if an object [not coded in python] has read-only attributes, so that the attempt to write would raise TypeError, then it do not have .__file__, so there will be an AttributeError, and there will not be a TypeError to catch.  This is true of CPython builtins.

>>> list.__file__
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    list.__file__
AttributeError: type object 'list' has no attribute '__file__'

>>> list.__file__ = ''
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    list.__file__ = ''
TypeError: can't set attributes of built-in/extension type 'list'

On the other hand, C-coded _tkinter has a re-writable .__file__. 
>>> import _tkinter
>>> _tkinter.__file__
'C:\\Programs\\Python27\\DLLs\\_tkinter.pyd'
>>> _tkinter.__file__ = ''

>From the minimal information given, it appears that clr defies this expectation by having an unwritable .__file__ attribute.  Hence the TypeError in abs_file.  Unless a read_only .__file__ is somewhere documented as prohibited, the bug seems to be not including TypeError in the exception tuple.

In 3.x, abs__file__ became abs_paths.  It has the same line with the same problem.

For testing, perhaps an instance of this in sys.modules would work.

class UnsettableFile:
    def __getattr__(self, name):
        return __file__
    def __setattr__(self, name, value):
        raise TypeError()

----------
stage: needs patch -> test needed
status:  -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31798>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:47:06 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:47:06 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1508525226.84.0.213398074469.issue31804@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +davin, pitrou, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:47:31 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:47:31 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1508525251.55.0.213398074469.issue31804@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:50:09 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:50:09 +0000
Subject: [issue31807] unitest.mock: Using autospec=True conflicts with 'wraps'
In-Reply-To: <1508287695.22.0.213398074469.issue31807@psf.upfronthosting.co.za>
Message-ID: <1508525409.08.0.213398074469.issue31807@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31807>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:50:30 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:50:30 +0000
Subject: [issue31807] unitest.mock: Using autospec=True conflicts with 'wraps'
In-Reply-To: <1508287695.22.0.213398074469.issue31807@psf.upfronthosting.co.za>
Message-ID: <1508525430.29.0.213398074469.issue31807@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31807>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:53:35 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:53:35 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1508525615.68.0.213398074469.issue31811@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Fri Oct 20 14:56:03 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 18:56:03 +0000
Subject: [issue31813] python -m ensurepip hangs
In-Reply-To: <1508341378.28.0.213398074469.issue31813@psf.upfronthosting.co.za>
Message-ID: <1508525763.85.0.213398074469.issue31813@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: python -m enshure pip stucks -> python -m ensurepip hangs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31813>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:00:38 2017
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 20 Oct 2017 19:00:38 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508526038.18.0.213398074469.issue31803@psf.upfronthosting.co.za>


Ethan Furman <ethan at stoneleaf.us> added the comment:

We definitely need time with either DeprecationWarning or FutureWarning before removing/substituting a function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:04:30 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 19:04:30 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1508526270.26.0.213398074469.issue31826@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +barry, serhiy.storchaka
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:15:44 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 20 Oct 2017 19:15:44 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1508526944.52.0.213398074469.issue31811@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

They are covered here: https://github.com/python/cpython/blob/4a2d00cb4525fcb3209f04531472ba6a359ed418/Doc/reference/compound_stmts.rst#coroutines

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:30:59 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Oct 2017 19:30:59 +0000
Subject: [issue31814] subprocess_fork_exec more stable with vfork
In-Reply-To: <1508343864.17.0.213398074469.issue31814@psf.upfronthosting.co.za>
Message-ID: <1508527859.57.0.213398074469.issue31814@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31814>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:32:25 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Oct 2017 19:32:25 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508527945.87.0.213398074469.issue31810@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:35:15 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 19:35:15 +0000
Subject: [issue31794] Issues with test.autotest
In-Reply-To: <1508067544.81.0.213398074469.issue31794@psf.upfronthosting.co.za>
Message-ID: <1508528115.03.0.213398074469.issue31794@psf.upfronthosting.co.za>


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

As I reported on #31761, the exact result of 'import test.autotest' depends on exactly how it is run and with what.  I suspect that OS might have an effect.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31794>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:39:56 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Oct 2017 19:39:56 +0000
Subject: [issue31761] Failures and crashes when running tests by import
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1508528396.91.0.213398074469.issue31761@psf.upfronthosting.co.za>


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

Victor, why do you persist in the nearly irrelevant focus on IDLE?  As I reported above, failures and crashes happen ***without*** involving IDLE.  Serhiy appears to report the same in #31794.

----------
title: Failures and crashes when running tests by import in IDLE -> Failures and crashes when running tests by import

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:40:30 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Oct 2017 19:40:30 +0000
Subject: [issue31203] socket.IP_PKTINFO is missing from python
In-Reply-To: <1502722784.42.0.622750235869.issue31203@psf.upfronthosting.co.za>
Message-ID: <1508528430.95.0.213398074469.issue31203@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
nosy: +`
stage:  -> commit review
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31203>
_______________________________________

From report at bugs.python.org  Fri Oct 20 15:57:18 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Oct 2017 19:57:18 +0000
Subject: [issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter
In-Reply-To: <1508407674.96.0.213398074469.issue31817@psf.upfronthosting.co.za>
Message-ID: <1508529438.53.0.213398074469.issue31817@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

You may need to set LD_LIBRARY_PATH env variable to point to your Tcl and Tk libraries or, better, add an rpath entry to LDFLAGS.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31817>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:06:45 2017
From: report at bugs.python.org (Josh Cullum)
Date: Fri, 20 Oct 2017 20:06:45 +0000
Subject: [issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter
In-Reply-To: <1508529438.53.0.213398074469.issue31817@psf.upfronthosting.co.za>
Message-ID: <CAEjmdv1Otg3Zi=R-MC59_Xbyw4OR3eQGmfQj27_dk6soYK1kdQ@mail.gmail.com>


Josh Cullum <joshua.cullum at gmail.com> added the comment:

Hi Ned,

LD_LIBRARY_PATH has been set with the lib paths for both, like I said the
module itself builds, I?ll add the module build logs later but the module
try?s to get loaded before the tests which unfortunately gives the error
undefined symbol: Tcl_GetCharLength
On Fri, 20 Oct 2017 at 20:57, Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at python.org> added the comment:
>
> You may need to set LD_LIBRARY_PATH env variable to point to your Tcl and
> Tk libraries or, better, add an rpath entry to LDFLAGS.
>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31817>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31817>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:09:07 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 20 Oct 2017 20:09:07 +0000
Subject: [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1508530147.55.0.213398074469.issue9842@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +4033
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9842>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:14:29 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Oct 2017 20:14:29 +0000
Subject: [issue31814] subprocess_fork_exec more stable with vfork
In-Reply-To: <1508343864.17.0.213398074469.issue31814@psf.upfronthosting.co.za>
Message-ID: <1508530469.41.0.213398074469.issue31814@psf.upfronthosting.co.za>


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

Using new syscalls for _posixsubprocess.c would be a feature so it would be limited to 3.7+ if done at all.

My gut feeling is that the real bug is in *any* library code that uses pthread_atfork() in a non thread safe manner.  That code is fundamentally broken as it is placing a burden upon the entire application that it lives within that the application and no other libraries may use threads or if it does that it may not launch subprocesses.

That is unrealistic.  So I'd blame OpenBlas and OpenMP.

Supporting alternate system calls seems like it would just paper over the issue of improper use of pthread_atfork rather than address the fundamental problem.

----------
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31814>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:14:47 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Oct 2017 20:14:47 +0000
Subject: [issue31814] subprocess_fork_exec more stable with vfork
In-Reply-To: <1508343864.17.0.213398074469.issue31814@psf.upfronthosting.co.za>
Message-ID: <1508530487.63.0.213398074469.issue31814@psf.upfronthosting.co.za>


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


----------
components: +Extension Modules -Interpreter Core
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31814>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:17:13 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Oct 2017 20:17:13 +0000
Subject: [issue31812] Document PEP 545 (documentation translation) in What's
 New in Python 3.7
In-Reply-To: <1508341337.17.0.213398074469.issue31812@psf.upfronthosting.co.za>
Message-ID: <1508530633.46.0.213398074469.issue31812@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4034
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31812>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:39:55 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Oct 2017 20:39:55 +0000
Subject: [issue31804] multiprocessing calls flush on sys.stdout at exit even
 if it is None (pythonw)
In-Reply-To: <1508252374.96.0.213398074469.issue31804@psf.upfronthosting.co.za>
Message-ID: <1508531995.03.0.213398074469.issue31804@psf.upfronthosting.co.za>


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

This looks to be a duplicate of https://bugs.python.org/issue28326

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> multiprocessing.Process depends on sys.stdout being open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31804>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:40:43 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Oct 2017 20:40:43 +0000
Subject: [issue31761] Failures and crashes when running tests by import
In-Reply-To: <1508528396.91.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ1P2otAzeyqJ8cN35WRZP0FS7JDxYC0DAy1avjFR=gbg@mail.gmail.com>


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

Sorry, I didn't read you comment. I just saw IDLE, I missed that you wrote
that the bug is unrelated to IDLE. Ooops

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:42:37 2017
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Oct 2017 20:42:37 +0000
Subject: [issue31781] crashes when calling methods of an uninitialized
 zipimport.zipimporter object
In-Reply-To: <1507913807.6.0.213398074469.issue31781@psf.upfronthosting.co.za>
Message-ID: <1508532157.17.0.213398074469.issue31781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:


New changeset db60a5bfa5d5f7a6f1538cc1fe76f0fda57b524e by Brett Cannon (Oren Milman) in branch 'master':
bpo-31781: Prevent crashes when calling methods of an uninitialized zipimport.zipimporter object (GH-3986)
https://github.com/python/cpython/commit/db60a5bfa5d5f7a6f1538cc1fe76f0fda57b524e


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31781>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:43:37 2017
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Oct 2017 20:43:37 +0000
Subject: [issue31781] crashes when calling methods of an uninitialized
 zipimport.zipimporter object
In-Reply-To: <1507913807.6.0.213398074469.issue31781@psf.upfronthosting.co.za>
Message-ID: <1508532217.22.0.213398074469.issue31781@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

As always, thanks for the fix, Oren!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31781>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:46:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Oct 2017 20:46:32 +0000
Subject: [issue31761] Failures and crashes when running tests by import
In-Reply-To: <1507740904.59.0.213398074469.issue31761@psf.upfronthosting.co.za>
Message-ID: <1508532392.5.0.213398074469.issue31761@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Perhaps there are issues specific to IDLE, but we should first fix issues not related to IDLE in #31794.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31761>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:49:47 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Oct 2017 20:49:47 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1508532587.64.0.213398074469.issue31756@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:59:08 2017
From: report at bugs.python.org (Roel van der Goot)
Date: Fri, 20 Oct 2017 20:59:08 +0000
Subject: [issue31830] asyncio.create_subprocess_exec doesn't capture all
 stdout output
Message-ID: <1508533148.51.0.213398074469.issue31830@psf.upfronthosting.co.za>


Change by Roel van der Goot <roelvandergoot at gmail.com>:


----------
components: asyncio
files: show.py
nosy: cannedrag, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.create_subprocess_exec doesn't capture all stdout output
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47228/show.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31830>
_______________________________________

From report at bugs.python.org  Fri Oct 20 16:59:16 2017
From: report at bugs.python.org (Mark Ignacio)
Date: Fri, 20 Oct 2017 20:59:16 +0000
Subject: [issue20825] containment test for "ip_network in ip_network"
In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
Message-ID: <1508533156.26.0.213398074469.issue20825@psf.upfronthosting.co.za>


Change by Mark Ignacio <mark at ignacio.io>:


----------
nosy: +Mark.Ignacio
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 17:12:35 2017
From: report at bugs.python.org (Mark Ignacio)
Date: Fri, 20 Oct 2017 21:12:35 +0000
Subject: [issue20825] containment test for "ip_network in ip_network"
In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
Message-ID: <1508533955.85.0.213398074469.issue20825@psf.upfronthosting.co.za>


Mark Ignacio <mark at ignacio.io> added the comment:

Hey Michel,

Are you still interested in pushing this patch through? It's be awesome if this got committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 18:22:57 2017
From: report at bugs.python.org (calimeroteknik)
Date: Fri, 20 Oct 2017 22:22:57 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
Message-ID: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>


New submission from calimeroteknik <calimeroteknik at free.fr>:

The following code excerpt demonstrates a crash:

import email.message
mail = email.message.EmailMessage()
mail.add_attachment(
   b"test",
   maintype = "text",
   subtype  = "plain",
   filename = "I thought I could put a few words in the filename but apparently it does not go so well.txt" 
)
print(mail)

Output on python 3.7.0a1: https://gist.github.com/altendky/33c235e8a693235acd0551affee0a4f6
Output on python 3.6.2: https://oremilac.tk/paste/python-rfc2231-oops.log


Additionally, a behavioral issue is demonstrated by replacing in the above:
filename = "What happens if we try French in here? touch?!.txt"


Which results in the following output (headers):

Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*=utf-8''What%20happens%20if%20we%20try%20French%20in%20here%3F%20touch%C3%A9%21.txt
MIME-Version: 1.0


Instead of, for example, this correct output (by Mozilla Thunderbird here):

Content-Type: text/plain; charset=UTF-8;
 name="=?UTF-8?Q?What_happens_if_we_try_French_in_here=3f_touch=c3=a9!.txt?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0*=utf-8''%57%68%61%74%20%68%61%70%70%65%6E%73%20%69%66%20%77%65;
 filename*1*=%20%74%72%79%20%46%72%65%6E%63%68%20%69%6E%20%68%65%72%65%3F;
 filename*2*=%20%74%6F%75%63%68%C3%A9%21%2E%74%78%74


Issues to note here:
-the "filename" parameter is not indented, mail clients ignore it
-the "filename" parameter is not split according to RFC 2231

The relevant standard is exemplified in section 4.1 of https://tools.ietf.org/html/rfc2231#page-5


Python 3.4.6 and 3.5.4 simply do not wrap anything, which works with  but is not conformant to standards.


Solving all of the above would imply correctly splitting any header.
Function "set_param" in /usr/lib/python*/email/message.py looked like a place to look.

Unfortunately I do not understand what's going on there very well.


As yet an additional misbehaviour to note, try to repeat the above print statement twice.
The result is not identical, and the second time you get the following output:

Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;*=utf-8''What%20happens%20if%20we%20try%20French%20in%20here%3F%20touch%C3%A9%21.txt
MIME-Version: 1.0

It would appear that "filename" has disappeared.
The issue does not reveal itself with simple values for the 'filename' argument, e.g. "test.txt".


PS: The above output also illustrates this (way more minor) issue: https://bugs.python.org/issue25235

----------
components: email
messages: 304684
nosy: barry, calimeroteknik, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.add_attachment(filename="long or sp?cial") crashes or produces invalid output
type: crash
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Fri Oct 20 18:27:45 2017
From: report at bugs.python.org (calimeroteknik)
Date: Fri, 20 Oct 2017 22:27:45 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
Message-ID: <1508538465.62.0.213398074469.issue31831@psf.upfronthosting.co.za>


calimeroteknik <calimeroteknik at free.fr> added the comment:

Erratum: the output generated by python 3.5 and 3.4 causes line wraps in the SMTP delivery chain, which cause exactly the same breakage as ulterior versions: the crucially needed indendation of one space ends up being absent.

----------
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Fri Oct 20 18:37:05 2017
From: report at bugs.python.org (Colin Dunklau)
Date: Fri, 20 Oct 2017 22:37:05 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1508539025.71.0.213398074469.issue31811@psf.upfronthosting.co.za>


Colin Dunklau <colin.dunklau at gmail.com> added the comment:

Hi Yury, perhaps I've misinterpreted PEP 492, and I can't claim to understand how the parser works and thus how the changes in https://github.com/python/cpython/pull/1669 affect things, but it seems to me that async and await are truly reserved words now, not just only reserved in certain contexts. If that's true, shouldn't they also appear in the list in the lexical analysis doc?

I'd appreciate any clarification you (or anyone else) can offer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Fri Oct 20 18:52:34 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 20 Oct 2017 22:52:34 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1508539954.6.0.213398074469.issue31811@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Ah, you mean this list: https://docs.python.org/3/reference/lexical_analysis.html#keywords ?

Your original link was a bit hard to read as it shows rest markup and not the actual list of keywords.  So I missed it, sorry.

I'll reopen the issue, please feel free to submit a PR!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Fri Oct 20 19:08:38 2017
From: report at bugs.python.org (Roel van der Goot)
Date: Fri, 20 Oct 2017 23:08:38 +0000
Subject: [issue31832] Async list comprehension (PEP 530) causes SyntaxError in
 Python 3.6.3
Message-ID: <1508540918.29.0.213398074469.issue31832@psf.upfronthosting.co.za>


New submission from Roel van der Goot <roelvandergoot at gmail.com>:

$ python3
Python 3.6.3 (default, Oct  3 2017, 21:45:48) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def arange(n):
...     for i in range(n):
...         yield i
... 
>>> [i async for i in arange(10)]
  File "<stdin>", line 1
    [i async for i in arange(10)]
           ^
SyntaxError: invalid syntax
>>>

----------
components: asyncio
messages: 304688
nosy: cannedrag, yselivanov
priority: normal
severity: normal
status: open
title: Async list comprehension (PEP 530) causes SyntaxError in Python 3.6.3
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31832>
_______________________________________

From report at bugs.python.org  Fri Oct 20 19:31:13 2017
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Oct 2017 23:31:13 +0000
Subject: [issue31832] Async list comprehension (PEP 530) causes SyntaxError in
 Python 3.6.3
In-Reply-To: <1508540918.29.0.213398074469.issue31832@psf.upfronthosting.co.za>
Message-ID: <1508542273.57.0.213398074469.issue31832@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Your async listcomp must also be defined within a coroutine to turn `async` into a keyword in 3.6.  The following is far from best practice (don't do this, I don't know what I'm doing! :), but at least it compiles and shows that it works:

async def arange(n):
    for i in range(n):
        yield i

async def alistcomp():
    return [i async for i in arange(10)]

try:
    next(alistcomp().__await__())
except StopIteration as e:
    value = e.value

print(value)

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31832>
_______________________________________

From report at bugs.python.org  Fri Oct 20 19:45:58 2017
From: report at bugs.python.org (Roel van der Goot)
Date: Fri, 20 Oct 2017 23:45:58 +0000
Subject: [issue31832] Async list comprehension (PEP 530) causes SyntaxError in
 Python 3.6.3
In-Reply-To: <1508540918.29.0.213398074469.issue31832@psf.upfronthosting.co.za>
Message-ID: <1508543158.9.0.213398074469.issue31832@psf.upfronthosting.co.za>


Roel van der Goot <roelvandergoot at gmail.com> added the comment:

Zachary,

Thank you for your response. I had the impression that async comprehensions are a bridge between async functions and non-async functions. Is there a wat to use async (and asyncio) and then go back to regular python? Or am I just wishful thinking? :-)

For example, it would be nice to start multiple processes through asyncio.create_subprocess_exec (or _shell) await twice and then process all the output in "traditional" (i.e., non-async) Python.

Cheers :),
Cannedrag

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31832>
_______________________________________

From report at bugs.python.org  Fri Oct 20 19:53:50 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 20 Oct 2017 23:53:50 +0000
Subject: [issue20825] containment test for "ip_network in ip_network"
In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
Message-ID: <1508543630.33.0.213398074469.issue20825@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests: +4035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20825>
_______________________________________

From report at bugs.python.org  Fri Oct 20 20:12:30 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Oct 2017 00:12:30 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
Message-ID: <1508544750.7.0.213398074469.issue31831@psf.upfronthosting.co.za>


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

Does the patch in gh-3488 fix this?  I think it should, or if it doesn't that's a bug in the PR patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Fri Oct 20 20:44:17 2017
From: report at bugs.python.org (Roel van der Goot)
Date: Sat, 21 Oct 2017 00:44:17 +0000
Subject: [issue31832] Async list comprehension (PEP 530) causes SyntaxError in
 Python 3.6.3
In-Reply-To: <1508540918.29.0.213398074469.issue31832@psf.upfronthosting.co.za>
Message-ID: <1508546657.87.0.213398074469.issue31832@psf.upfronthosting.co.za>


Roel van der Goot <roelvandergoot at gmail.com> added the comment:

I have been thinking about my previous comment a bit more. For consistency there should at least be an await somewhere to move back from async land to non-async land.

For example:

    #!/usr/bin/env python3

    import asyncio

    async def main():
        cmds = [['ssh', 'user at host', 'echo {}'.format(i)] for i in range(4)]
        creations = [asyncio.create_subprocess_exec(*cmd, 
                stdout=asyncio.subprocess.PIPE, 
                stderr=asyncio.subprocess.PIPE)
                    for cmd in cmds]
        processes = [await creation for creation in creations]
        outputs = [await process.communicate() for process in processes]
        print(outputs)
    
    if __name__ == '__main__':
        event_loop = asyncio.get_event_loop()
        event_loop.run_until_complete(main())

prints

    [(b'0\n', b''), (b'1\n', b''), (b'2\n', b''), (b'3\n', b'')]

It would be nice if you could somehow return outputs from main() and process the results in a non-async function. There are no async concepts left in outputs after all. But I am not aware of a way you can do this in Python currently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31832>
_______________________________________

From report at bugs.python.org  Fri Oct 20 23:19:19 2017
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 21 Oct 2017 03:19:19 +0000
Subject: [issue31832] Async list comprehension (PEP 530) causes SyntaxError in
 Python 3.6.3
In-Reply-To: <1508540918.29.0.213398074469.issue31832@psf.upfronthosting.co.za>
Message-ID: <1508555959.97.0.213398074469.issue31832@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

That's already provided, just do `return outputs` instead of `print(outputs)`, and `outputs = event_loop.run_until_complete(main())`.  See https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.AbstractEventLoop.run_until_complete

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31832>
_______________________________________

From report at bugs.python.org  Fri Oct 20 23:58:39 2017
From: report at bugs.python.org (Roel van der Goot)
Date: Sat, 21 Oct 2017 03:58:39 +0000
Subject: [issue31832] Async list comprehension (PEP 530) causes SyntaxError in
 Python 3.6.3
In-Reply-To: <1508540918.29.0.213398074469.issue31832@psf.upfronthosting.co.za>
Message-ID: <1508558319.02.0.213398074469.issue31832@psf.upfronthosting.co.za>


Roel van der Goot <roelvandergoot at gmail.com> added the comment:

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31832>
_______________________________________

From report at bugs.python.org  Sat Oct 21 00:32:22 2017
From: report at bugs.python.org (emtone)
Date: Sat, 21 Oct 2017 04:32:22 +0000
Subject: [issue31833] Compile fail on gentoo for MIPS CPU of loongson 2f
Message-ID: <1508560342.69.0.213398074469.issue31833@psf.upfronthosting.co.za>


New submission from emtone <tong__hui at 163.com>:

Here is the error message:
building '_multiprocessing' extension
creating
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing
mips64el-unknown-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -O2
-march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fwrapv -DNDEBUG
-IModules/_multiprocessing -I. -IInclude -I/usr/local/include
-I/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Include
-I/var/tmp/portage/dev-lang/python-2.7.12/work/mips64el-unknown-linux-gnu
-c /var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/multiprocessing.c
-o
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/multiprocessing.o
mips64el-unknown-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -O2
-march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fwrapv -DNDEBUG
-IModules/_multiprocessing -I. -IInclude -I/usr/local/include
-I/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Include
-I/var/tmp/portage/dev-lang/python-2.7.12/work/mips64el-unknown-linux-gnu
-c /var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/socket_connection.c
-o
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/socket_connection.o
mips64el-unknown-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -O2
-march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fwrapv -DNDEBUG
-IModules/_multiprocessing -I. -IInclude -I/usr/local/include
-I/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Include
-I/var/tmp/portage/dev-lang/python-2.7.12/work/mips64el-unknown-linux-gnu
-c /var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/semaphore.c
-o
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/semaphore.o
mips64el-unknown-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed
-L. -Wl,-O1 -Wl,--as-needed -L. -fno-strict-aliasing -O2
-march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fwrapv -DNDEBUG -I.
-IInclude
-I/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Include
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/multiprocessing.o
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/socket_connection.o
build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.12/work/Python-2.7.12/Modules/_multiprocessing/semaphore.o
-L. -lpython2.7 -o build/lib.linux-mips64-2.7/_multiprocessing.so ***
WARNING: importing extension "_multiprocessing" failed with <type
'exceptions.OSError'>: [Errno 89] Function not implemented

----------
components: Extension Modules
messages: 304695
nosy: emtone
priority: normal
severity: normal
status: open
title: Compile fail on gentoo for MIPS CPU of loongson 2f
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31833>
_______________________________________

From report at bugs.python.org  Sat Oct 21 03:57:11 2017
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 21 Oct 2017 07:57:11 +0000
Subject: [issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower
 than reference
Message-ID: <1508572631.92.0.213398074469.issue31834@psf.upfronthosting.co.za>


New submission from Micha? G?rny <mgorny at gentoo.org>:

The setup.py file for Python states:

        if (not cross_compiling and
                os.uname().machine == "x86_64" and
                sys.maxsize >  2**32):
            # Every x86_64 machine has at least SSE2.  Check for sys.maxsize
            # in case that kernel is 64-bit but userspace is 32-bit.
            blake2_macros.append(('BLAKE2_USE_SSE', '1'))

While the assertion about having SSE2 is true, it doesn't mean that it's worthwhile to use. I've tested pure (i.e. without SSSE3 and so on) on three different machines, getting the following results:

Athlon64 X2 (SSE2 is the best supported variant), 540 MiB of data:

SSE2: [5.189988004000043, 5.070812243997352]
ref:  [2.0161159170020255, 2.0475422790041193]

Core i3, same data file:

SSE2: [1.924425926999902, 1.92461746999993, 1.9298037500000191]
ref:  [1.7940209749999667, 1.7900855569999976, 1.7835538760000418]

Xeon E5630 server, 230 MiB data file:

SSE2: [0.7671358410007088, 0.7797677099879365, 0.7648976119962754]
ref:  [0.5784736709902063, 0.5717909929953748, 0.5717219939979259]

So in all the tested cases, pure SSE2 implementation is *slower* than the reference implementation. SSSE3 and other variants are faster and AFAIU they are enabled automatically based on CFLAGS, so it doesn't matter for most of the systems.

However, for old CPUs that do not support SSSE3, the choice of SSE2 makes the algorithm prohibitively slow -- it's 2.5 times slower than the reference implementation!

----------
components: Extension Modules
messages: 304696
nosy: mgorny
priority: normal
severity: normal
status: open
title: BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower than reference
type: performance
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31834>
_______________________________________

From report at bugs.python.org  Sat Oct 21 04:07:56 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Oct 2017 08:07:56 +0000
Subject: [issue31828] Support Py_tss_NEEDS_INIT outside of static
 initialisation
In-Reply-To: <1508515676.46.0.213398074469.issue31828@psf.upfronthosting.co.za>
Message-ID: <1508573276.8.0.213398074469.issue31828@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Right, the cases we were aiming to cover were:

- C variable declarations ("static Py_tss_t tss_key = Py_tss_NEEDS_INIT;")
- dynamic allocation with PyThread_tss_alloc
- resetting a key back to the uninitialised state with PyThread_tss_delete

The problem we have is that the second field in Py_tss_t is platform dependent, and not all platforms define a safe "unused" value for their NATIVE_TSS_KEY_T, which means Py_tss_NEEDS_INIT ends up being only a partial initialiser (earlier versions of the PEP used a field initialiser, but we were asked to switch it to a partial initialiser in order to support more compilers).

We *could* offer a `PyThread_tss_reset` (to reset a key back to Py_tss_NEEDS_INIT), but that's confusingly similar to PyThread_tss_delete.

Another option would be to check for typed partial initialiser support in the configure script, and declare Py_tss_NEEDS_INIT accordingly. However, that wouldn't solve the problem for any clients that are themselves also attempting to write cross-platform code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31828>
_______________________________________

From report at bugs.python.org  Sat Oct 21 04:18:44 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Oct 2017 08:18:44 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1508573924.38.0.213398074469.issue16737@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Is there a relevant discrepancy other than __file__ sometimes being absolute?

If code wants to be certain that __file__ is relative to the current directory, they need to run it through os.relpath() - there's no requirement for implementations one way or the other as to whether __file__ is absolute or relative

If we changed anything in CPython, it would be to make __main__.__file__ always absolute, even for scripts - we already changed plain imports to work that way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:18:49 2017
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 21 Oct 2017 09:18:49 +0000
Subject: [issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower
 than reference
In-Reply-To: <1508572631.92.0.213398074469.issue31834@psf.upfronthosting.co.za>
Message-ID: <1508577529.86.0.213398074469.issue31834@psf.upfronthosting.co.za>


Change by Micha? G?rny <mgorny at gentoo.org>:


----------
keywords: +patch
pull_requests: +4036
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31834>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:34:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 09:34:24 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1504175392.51.0.871887341171.issue31314@psf.upfronthosting.co.za>
Message-ID: <1508578464.61.0.213398074469.issue31314@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:37:20 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 09:37:20 +0000
Subject: [issue31829] Portability issues with pickle
In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za>
Message-ID: <1508578640.38.0.213398074469.issue31829@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4038
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31829>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:38:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 09:38:16 +0000
Subject: [issue31314] email throws exception with oversized header input
In-Reply-To: <1504175392.51.0.871887341171.issue31314@psf.upfronthosting.co.za>
Message-ID: <1508578696.78.0.213398074469.issue31314@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -4037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31314>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:53:03 2017
From: report at bugs.python.org (tzickel)
Date: Sat, 21 Oct 2017 09:53:03 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508579583.34.0.213398074469.issue25083@psf.upfronthosting.co.za>


tzickel <icebreak at yahoo.com> added the comment:

OK, This issue has been biting me a few more times in production, so for now I've added the environment variable PYTHONDONTWRITEBYTECODE which resolves it (but it's a hack). I'm sure I am not the only one with it (recall that this is happening in a complex setup where I run python in windows via a network drive hosted in netapp, and runs thousands of times from many machines).

So, I've been looking for a simple way to show you it's a major fault at the python 2 import I/O error checking, and found that new strace has fault injection capability :)

In this demo I'll be running under debian sid (has strace version high enough for fault injection and latest python 2), you can use docker if you don't have it.

On my mac, I'm running (this example is on one of python's init modules, but of course can happen on any .py file):
----
user$ docker run -it --cap-add SYS_PTRACE debian:sid
----
The cap-add is needed for strace to run.
----
root at 2dcc36934ea6:/# apt-get update && apt-get install -y strace python

root at 2dcc36934ea6:/# python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
----
Python works just fine.
----
root at 2dcc36934ea6:/# strace -P /usr/lib/python2.7/sre_parse.pyc -P /usr/lib/python2.7/sre_parse.py -e trace=read -e fault=read python
read(7, 0x55c3ac2ad900, 4096)           = -1 EPERM (Operation not permitted) (INJECTED)
...
read(6, 0x55c3ac2cb680, 4096)           = -1 EPERM (Operation not permitted) (INJECTED)
...
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 554, in <module>
    main()
...
  File "/usr/lib/python2.7/sre_compile.py", line 572, in compile
    p = sre_parse.parse(p, flags)
AttributeError: 'module' object has no attribute 'parse'
+++ exited with 1 +++
----
This command simply causes the python process to fail the read command on the files sre_parse.py and sre_parse.pyc (the .pyc btw already existed from previous run).
This should be OK, since it can't read a required module form disk.
----
root at 2dcc36934ea6:/# python
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 554, in <module>
    main()
...
  File "/usr/lib/python2.7/sre_compile.py", line 572, in compile
    p = sre_parse.parse(p, flags)
AttributeError: 'module' object has no attribute 'parse'
----
This is already bad, python does not work anymore, now even without an I/O error :(
----
root at 2dcc36934ea6:/# ls -l /usr/lib/python2.7/sre_parse.pyc
-rw-r--r-- 1 root root 118 Oct 21 09:20 /usr/lib/python2.7/sre_parse.pyc
----
If we check, we see that the previous python instance with I/O error created an empty byte code valid sre_parse.pyc (you can check it by dis.dis it, and see it's empty code object), this is the crux of the bug.
----
root at 2dcc36934ea6:/# rm /usr/lib/python2.7/sre_parse.pyc
----
let's delete the bad .pyc file
----
root at 2dcc36934ea6:/# python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
----
yey, python works now again
----
root at 2dcc36934ea6:/# ls -l /usr/lib/python2.7/sre_parse.pyc
-rw-r--r-- 1 root root 21084 Oct 21 09:20 /usr/lib/python2.7/sre_parse.pyc
----
We can see now that the .pyc file has a much bigger size (21084 bytes compared to 118 from before)
----
root at 2dcc36934ea6:/# strace -P /usr/lib/python2.7/sre_parse.pyc -P /usr/lib/python2.7/sre_parse.py -e trace=read -e fault=read python -B
read(7, 0x55ceb72a7900, 4096)           = -1 EPERM (Operation not permitted) (INJECTED)
...
read(6, 0x55ceb72c5680, 4096)           = -1 EPERM (Operation not permitted) (INJECTED)
...
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 554, in <module>
    main()
...
AttributeError: 'module' object has no attribute 'parse'
+++ exited with 1 +++
----
We can now try this issue with python -B which should not try to create .pyc files
----
root at 2dcc36934ea6:/# python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()
----
yey, python still works (hopefully if this is an network I/O error, it will stop occurring on a future run with a watchdog for an server app)
----

A less likely variant (but possible) is that if the .pyc does not exist, and you have an I/O error on importing the .py, it will produce an bad .pyc file, you can try it:
root at 2dcc36934ea6:/# rm /usr/lib/python2.7/sre_parse.pyc
root at 2dcc36934ea6:/# strace -P /usr/lib/python2.7/sre_parse.py -e trace=read -e fault=read python
root at 2dcc36934ea6:/# python
Python will not work until you delete the .pyc file.

----

(*) The I/O error needs to occur when the AST parser will still produce a valid code object, this easily happens when the error is just when starting to read the file (will produce an empty code AST which will create an empty code object)

----

You can install python3 and see that it doesn't effect it the same way (i.e. it will abort on the I/O error, but it won't produce a bad .pyc file, since it has much better I/O error handling)

----
root at 5ef2a0658fa8:/# strace -P /usr/lib/python3.5/encodings/aliases.py -P /usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc -e trace=read -e fault=read python3
....
Aborted

root at 5ef2a0658fa8:/# python3
Python 3.5.2 (default, Sep 14 2017, 22:51:06)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

----
The patch previously included should fix this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:55:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 09:55:03 +0000
Subject: [issue31829] Portability issues with pickle
In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za>
Message-ID: <1508579703.27.0.213398074469.issue31829@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 4067 fixes following issues when unpickle on Unix or in binary mode files written with protocol 0 in text mode on Windows:

* ints were unpickled as longs by cPickle.
* bools were unpickled as longs by cPickle and as ints by pickle.
* floats couldn't be unpickled by cPickle.
* strings couldn't be unpickled by pickle.
* instances and globals couldn't be unpickled. And error messages were confusing due to invisible \r.
* pickles with protocol 0 containing Unicode string with \x1a couldn't be unpickled on Windows in text mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31829>
_______________________________________

From report at bugs.python.org  Sat Oct 21 05:58:03 2017
From: report at bugs.python.org (tzickel)
Date: Sat, 21 Oct 2017 09:58:03 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508579883.88.0.213398074469.issue25083@psf.upfronthosting.co.za>


tzickel <icebreak at yahoo.com> added the comment:

Ignore the hash append / link at the start of each shell command (it's the output from docker, and not related to python commits).

BTW, forgot to mention, of course when doing the fault injection on the .py files, the error is bad as well, it should be I/O error, and instead it shows that it's an empty module:
AttributeError: 'module' object has no attribute 'parse'

(The patch actually fixes that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Sat Oct 21 07:14:04 2017
From: report at bugs.python.org (Anselm Kruis)
Date: Sat, 21 Oct 2017 11:14:04 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
Message-ID: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>


New submission from Anselm Kruis <a.kruis at science-computing.de>:

Just a minor performance issue.

The C functions _PyFunction_FastCallDict() and _PyFunction_FastCallKeywords() (branch 'master', Objects/call.c) and their predecessors fast_function() and _PyFunction_FastCallDict() in Python/ceval.c all contain the following sub-expression in the "if"-statement for the fast-path. For instance Objects/call.c:318

 co->co_flags == (CO_OPTIMIZED | CO_NEWLOCALS | CO_NOFREE)

Now, if co_flags has any of the CO_FUTURE_... bits set, the expression is always False and the fast path is not used.

Currently this affects only Python 3.6 and Python 2.7, because other Python versions do not use the __future__ mechanism.

The fix is simple. Replace the faulty sub-expression by

 (co->co_flags & (~PyCF_MASK)) == (CO_OPTIMIZED | CO_NEWLOCALS | CO_NOFREE))

I discovered this issue while debugging reference leaks in Stackless Python a few month ago. It is hard to write a test case, but one can compare C call stacks using a debugger.

$ ulimit -c unlimited  # enable core dumps
$ python3.6 -c 'from __future__ import generator_stop; import os; (lambda: os.abort())()'
$ gdb -batch -ex bt  python3.6 core > trace_with_future
$ python3.6 -c 'import os; (lambda: os.abort())()'
$ gdb -batch -ex bt  python3.6 core > trace_without_future

If you compare the traces, the difference is in stack frame #9. Same for python2.7.

----------
components: Interpreter Core
messages: 304702
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: _PyFunction_FastCallDict and _PyFunction_FastCallKeywords: fast path not used
type: performance
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Sat Oct 21 09:08:05 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 21 Oct 2017 13:08:05 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1508591285.0.0.213398074469.issue16737@psf.upfronthosting.co.za>


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

The other major difference and the only one that's affected me is the presence of sys.path[0] == ''.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Sat Oct 21 09:21:13 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Oct 2017 13:21:13 +0000
Subject: [issue26858] setting SO_REUSEPORT fails
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1508592073.03.0.213398074469.issue26858@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Philip, 9791c5d55f52 was commited in november 2013 and issue19901 was closed in december 2013, so how can they be an appropriate solution for a problem reported on 2017-01-13 in msg285392 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26858>
_______________________________________

From report at bugs.python.org  Sat Oct 21 09:49:54 2017
From: report at bugs.python.org (calimeroteknik)
Date: Sat, 21 Oct 2017 13:49:54 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
Message-ID: <1508593794.56.0.213398074469.issue31831@psf.upfronthosting.co.za>


calimeroteknik <calimeroteknik at free.fr> added the comment:

I confirm that as for the crash, the patch in gh-3488 fixes it.
The first code excerpt in my initial report now outputs the following, valid headers:

Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0*=utf-8''I%20thought%20I%20could%20put%20a%20few%20words%20in%20th;
 filename*1*=e%20filename%20but%20apparently%20it%20does%20not%20go%20so%20we;
 filename*2*=ll.txt
MIME-Version: 1.0


However, when Unicode is added and the filename is short, things don't look right, this code:

import email.message
mail = email.message.EmailMessage()
mail.add_attachment(b"test", maintype="text", subtype="plain", filename="?.txt")
print(mail)

Results in these headers:

Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="?.txt"
MIME-Version: 1.0

To begin with, it is easy to deduce that there is no way to know that this '?' character is UTF-8.
And it's two 8-bit values at east one of which is detectably outside of 7-bit US-ASCII.


Quoting https://tools.ietf.org/html/rfc2231#page-4:
>a lightweight encoding mechanism is needed to accommodate 8-bit information in parameter values.

The 8-bit encoding goes straight through instead of undergoing the encoding process, which seems required in my interpretation of RFC2231.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Sat Oct 21 09:55:37 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Oct 2017 13:55:37 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
Message-ID: <1508594137.0.0.213398074469.issue31831@psf.upfronthosting.co.za>


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

You are correct, that is a bug.  Presumably I forgot to check for non-ascii when the parameter value doesn't need to be folded.  I'm not sure when I'll have time to look at this, unfortunately :(.  If you can see how to fix it, you could submit a PR against my PR branch, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Sat Oct 21 10:13:11 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Oct 2017 14:13:11 +0000
Subject: [issue20210] Support the *disabled* marker in Setup files
In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>
Message-ID: <1508595191.81.0.213398074469.issue20210@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests:  -2537

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

From report at bugs.python.org  Sat Oct 21 11:12:36 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Oct 2017 15:12:36 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1508598756.98.0.213398074469.issue16737@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, that one I definitely think could be improved. Could you file a separate RFE suggesting that we update sys.path[0] based on __main__.__spec__.origin after we look up __main__.__spec__?

That way it will only stay as the current directory if the module being executed is in a subdirectory of the current directory, and will otherwise be updated appropriately for wherever we actually found the main module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Sat Oct 21 11:43:52 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 21 Oct 2017 15:43:52 +0000
Subject: [issue26858] setting SO_REUSEPORT fails
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1508600632.47.0.213398074469.issue26858@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I assume he means that a similar piece of code should be inserted elsewhere. I am still waiting for Philip's PR though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26858>
_______________________________________

From report at bugs.python.org  Sat Oct 21 12:03:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 16:03:19 +0000
Subject: [issue31836] test_code_module fails after test_idle
Message-ID: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

$ ./python -m test -uall test_idle test_code_module
Run tests sequentially
0:00:00 load avg: 0.42 [1/2] test_idle
0:00:02 load avg: 0.42 [2/2] test_code_module
test test_code_module failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_code_module.py", line 35, in test_ps1
    self.assertEqual(self.sysmod.ps1, '>>> ')
AssertionError: <MagicMock name='sys.ps1' id='140109331413008'> != '>>> '

test_code_module failed
1 test OK.

1 test failed:
    test_code_module

Total duration: 2 sec
Tests result: FAILURE

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 304709
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: test_code_module fails after test_idle
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sat Oct 21 12:04:25 2017
From: report at bugs.python.org (tzickel)
Date: Sat, 21 Oct 2017 16:04:25 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508601865.62.0.213398074469.issue25083@psf.upfronthosting.co.za>


tzickel <icebreak at yahoo.com> added the comment:

Added a script to check if the bug exists (provided you have an updated strace 4.15 or above).

Without patch:
# ./import_io_check.sh
strace: Requested path 'tmp.py' resolved into '/root/tmp.py'
read(3, 0x55fc3a71cc50, 4096)           = -1 ENOSYS (Function not implemented) (INJECTED)
read(3, 0x55fc3a71cc50, 4096)           = -1 ENOSYS (Function not implemented) (INJECTED)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named py
+++ exited with 1 +++
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named py
Bug exists an incorrect .pyc has been produced

With patch:
# PYTHON=Python-2.7.14-with-patch/python ./import_io_check.sh
strace: Requested path 'tmp.py' resolved into '/root/tmp.py'
read(3, 0x55a8ff7d3020, 4096)           = -1 ENOSYS (Function not implemented) (INJECTED)
read(3, 0x55a8ff7d3020, 4096)           = -1 ENOSYS (Function not implemented) (INJECTED)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "tmp.py", line 1

    ^
SyntaxError: unexpected EOF while parsing
+++ exited with 1 +++
Script finished successfully

----------
nosy: +brett.cannon
Added file: https://bugs.python.org/file47229/import_io_check.sh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Sat Oct 21 12:15:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 16:15:08 +0000
Subject: [issue30156] PYTHONDUMPREFS segfaults on exit
In-Reply-To: <1493055827.6.0.962682353128.issue30156@psf.upfronthosting.co.za>
Message-ID: <1508602508.34.0.213398074469.issue30156@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Result on the same computer:
 
Mean +- std dev: [python0] 146 ns +- 5 ns -> [python] 206 ns +- 2 ns: 1.41x slower (+41%)

The difference now is smaller (41% instead of 58%) because calling with a tuple now is 16% slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30156>
_______________________________________

From report at bugs.python.org  Sat Oct 21 12:39:34 2017
From: report at bugs.python.org (Oren Milman)
Date: Sat, 21 Oct 2017 16:39:34 +0000
Subject: [issue31486] calling a _json.Encoder object raises a SystemError in
 case obj.items() returned a tuple
In-Reply-To: <1505496099.07.0.410774221671.issue31486@psf.upfronthosting.co.za>
Message-ID: <1508603974.52.0.213398074469.issue31486@psf.upfronthosting.co.za>


Oren Milman <orenmn at gmail.com> added the comment:

ISTM that PR 3840 resolved this issue (as part of bpo-28280).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31486>
_______________________________________

From report at bugs.python.org  Sat Oct 21 12:57:54 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Oct 2017 16:57:54 +0000
Subject: [issue28326] multiprocessing.Process depends on sys.stdout being open
In-Reply-To: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za>
Message-ID: <1508605074.22.0.213398074469.issue28326@psf.upfronthosting.co.za>


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

In issue31804, we see that sys.stdout and sys.stderr can sometimes simply be None, so we must check for that too.

----------
nosy: +pitrou
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28326>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:00:42 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Oct 2017 17:00:42 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1508605242.01.0.213398074469.issue6721@psf.upfronthosting.co.za>


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

I think we should somehow move forward on this, at least for logging locks which can be quite an annoyance.

There are two possible approaches:
- either a generic mechanism as posted by sbt in reinit_locks_2.diff
- or a logging-specific fix using os.register_at_fork()

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:08:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 17:08:02 +0000
Subject: [issue31837] ParseError in test_all_project_files()
Message-ID: <1508605682.35.0.213398074469.issue31837@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

test_all_project_files() in test_lib2to3 emits warnings in verbose mode.

/home/serhiy/py/cpython/Lib/lib2to3/tests/test_parser.py:415: UserWarning: ParseError on file /home/serhiy/py/cpython/Lib/lib2to3/main.py (bad input: type=22, value='=', context=('', (130, 38)))
  warnings.warn('ParseError on file %s (%s)' % (filepath, err))
/home/serhiy/py/cpython/Lib/lib2to3/tests/test_parser.py:415: UserWarning: ParseError on file /home/serhiy/py/cpython/Lib/lib2to3/tests/pytree_idempotency.py (bad input: type=22, value='=', context=('', (49, 33)))
  warnings.warn('ParseError on file %s (%s)' % (filepath, err))

ParseError is raised by lines like:

    print("Use --help to show usage.", file=sys.stderr)

Seems "from __future__ import print_function" doesn't work.

----------
components: 2to3 (2.x to 3.x conversion tool), Tests
messages: 304715
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ParseError in test_all_project_files()
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31837>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:12:00 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Oct 2017 17:12:00 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1508605920.46.0.213398074469.issue6721@psf.upfronthosting.co.za>


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

Oh, I forgot that IO buffered objects also have a lock.  So we would have to special-case those as well, unless we take the generic approach...

A problem with the generic approach is that it would leave higher-level synchronization objects such as RLock, Event etc. in an inconsistent state.  Not to mention the case where the lock is taken by the thread calling fork()...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:14:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 17:14:52 +0000
Subject: [issue29802] A possible null-pointer dereference in
 struct.s_unpack_internal()
In-Reply-To: <1489379218.66.0.044857321803.issue29802@psf.upfronthosting.co.za>
Message-ID: <1508606092.55.0.213398074469.issue29802@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4039

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29802>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:18:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 17:18:52 +0000
Subject: [issue28280] Always return a list from
 PyMapping_Keys/PyMapping_Values/PyMapping_Items
In-Reply-To: <1474913626.43.0.560302545775.issue28280@psf.upfronthosting.co.za>
Message-ID: <1508606332.4.0.213398074469.issue28280@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28280>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:20:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 17:20:38 +0000
Subject: [issue31486] calling a _json.Encoder object raises a SystemError in
 case obj.items() returned a tuple
In-Reply-To: <1505496099.07.0.410774221671.issue31486@psf.upfronthosting.co.za>
Message-ID: <1508606438.69.0.213398074469.issue31486@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31486>
_______________________________________

From report at bugs.python.org  Sat Oct 21 13:22:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 17:22:48 +0000
Subject: [issue28655] Tests altered the execution environment in isolated mode
In-Reply-To: <1478767618.32.0.527967950395.issue28655@psf.upfronthosting.co.za>
Message-ID: <1508606568.08.0.213398074469.issue28655@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +ParseError in test_all_project_files()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28655>
_______________________________________

From report at bugs.python.org  Sat Oct 21 14:07:39 2017
From: report at bugs.python.org (jfbu)
Date: Sat, 21 Oct 2017 18:07:39 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1508609259.14.0.213398074469.issue31589@psf.upfronthosting.co.za>


Change by jfbu <jfbu at free.fr>:


----------
pull_requests: +4040

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sat Oct 21 14:44:40 2017
From: report at bugs.python.org (jfbu)
Date: Sat, 21 Oct 2017 18:44:40 +0000
Subject: [issue31589] Links for French documentation PDF is broken: LaTeX
 issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1508611480.95.0.213398074469.issue31589@psf.upfronthosting.co.za>


jfbu <jfbu at free.fr> added the comment:

I have made a PR at https://github.com/python/cpython/pull/4069 which enhances `conf.py` with some pdflatex extra Unicode configuration. I tested it with building PDF English documentation at master (at https://github.com/python/cpython/tree/db60a5bfa5d5f7a6f1538cc1fe76f0fda57b524e) and at 3.6 branch (at https://github.com/python/cpython/tree/1e78ed6825701029aa45a68f9e62dd3bb8d4e928) and also French documentation at 3.6 (at https://github.com/python/python-docs-fr/commit/76b522b79c3caa26658920c714acf8fac0c20eeb). The changes are only for ``pdflatex`` builds: if `latex_engine` is set to `xelatex`, `lualatex`, or `platex` (automatic if language is `ja`), nothing is modified.

----------
nosy: +jfbu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sat Oct 21 14:59:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 18:59:25 +0000
Subject: [issue29802] A possible null-pointer dereference in
 struct.s_unpack_internal()
In-Reply-To: <1489379218.66.0.044857321803.issue29802@psf.upfronthosting.co.za>
Message-ID: <1508612365.54.0.213398074469.issue29802@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 73c4708630f99b94c35476529748629fff1fc63e by Serhiy Storchaka in branch 'master':
Fix bytes warnings in test_struct (added in bpo-29802). (#4068)
https://github.com/python/cpython/commit/73c4708630f99b94c35476529748629fff1fc63e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29802>
_______________________________________

From report at bugs.python.org  Sat Oct 21 15:24:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Oct 2017 19:24:48 +0000
Subject: [issue31827] Remove os.stat_float_times()
In-Reply-To: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>
Message-ID: <1508613888.15.0.213398074469.issue31827@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

stat_result is a named 10-tuple, containing several additional attributes. The last three items are st_atime, st_mtime and st_ctime as integers. Accessing them by name returns floats. Isn't a time to make them floats when access stat_result as a tuple?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Sat Oct 21 15:46:20 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Oct 2017 19:46:20 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1508615180.02.0.213398074469.issue31836@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +4041
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:06:52 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Oct 2017 20:06:52 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1508616412.3.0.213398074469.issue31836@psf.upfronthosting.co.za>


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

Running test_code_module afte test_idle, which somewhere executes idle code that sets sys.ps1, exposed a deficiency in test_code_module.

TestInteractiveConsole.test_ps1 is intended to test this code in InteractiveConsole.interact.

        try:
            sys.ps1
        except AttributeError:
            sys.ps1 = ">>> "

The existing test only tried to test the except branch, but without insuring that the AttributeError occurs.  PR 4070 fixes that and adds a test of the try branch, that sys.ps1 is respected and left alone (and later used as it) when present.  Ditto for test_ps2.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:11:36 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Oct 2017 20:11:36 +0000
Subject: [issue27640] add the '--disable-test-suite' option to configure
In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za>
Message-ID: <1508616696.4.0.213398074469.issue27640@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

> Ah, the discussion restarted on the other issue: http://bugs.python.org/issue20210#msg287516

Issue 20210 has ended up as a change in the build system eventually and not the installation process, only a tiny step towards the configuration of a smaller Python distribution :(

After browsing again the last discussion on "[Python-ideas] size of the installation of Python on mobile devices" [1], I find all the arguments in favor of such changes still relevant. I would also add the following new arguments:

* One frequent argument used against those changes is that "[packagers for mobile and embedded devices] will have to patch the code base anyway to get things working in such an environment". But this is not true, see issue 30386 (Add a build infrastructure for Android) that proposes an addition to Python that does not modify a SINGLE LINE in the existing source code. So it is not true (or at least not anymore true) that packagers for mobile and embedded devices need to patch the code base anyway.

* When Python is installed by the termux [2] Android application on an Android device, the size of the installed standard library is 34M. The termux installation script does not install the following files [3]:

    TERMUX_PKG_RM_AFTER_INSTALL="
    bin/python${_MAJOR_VERSION}m bin/idle*
    lib/python${_MAJOR_VERSION}/idlelib
    lib/python${_MAJOR_VERSION}/test
    lib/python${_MAJOR_VERSION}/tkinter
    lib/python${_MAJOR_VERSION}/turtledemo
    "

But it fails to not install also:
    lib/python${_MAJOR_VERSION}/config-${_MAJOR_VERSION}m
    lib/python${_MAJOR_VERSION}/ctypes/test
    lib/python${_MAJOR_VERSION}/distutils/tests
    lib/python${_MAJOR_VERSION}/sqlite3/test
    lib/python${_MAJOR_VERSION}/unittest/test

This is not consistent and should be fixed by a proper (endorsed by Python) installation process.

[1] https://mail.python.org/pipermail/python-ideas/2016-July/
[2] https://termux.com/
[3] https://github.com/termux/termux-packages/blob/master/packages/python/build.sh

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:24:03 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Oct 2017 20:24:03 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1508617443.54.0.213398074469.issue6721@psf.upfronthosting.co.za>


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


----------
pull_requests: +4042

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:27:53 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Oct 2017 20:27:53 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1508617673.07.0.213398074469.issue6721@psf.upfronthosting.co.za>


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

logging is pretty easy to deal with so I created a PR.

bufferedio.c is a little more work as we either need to use the posixmodule.c os.register_at_fork API or expose it as an internal C API to be able to call it to add acquires and releases around the buffer's self->lock member when non-NULL.  either way, that needs to be written safely so that it doesn't crash if fork happens after a buffered io struct is freed.  (unregister at fork handlers when freeing it? messy)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:29:53 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Oct 2017 20:29:53 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1508617673.07.0.213398074469.issue6721@psf.upfronthosting.co.za>
Message-ID: <7050cf02-974a-8d52-9df8-5a5886ea97c9@free.fr>


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

Actually, we already have a doubly-linked list of buffered IO objects
(for another purpose), so we can reuse that and register a single set of
global callbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6721>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:33:11 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Oct 2017 20:33:11 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508617991.01.0.213398074469.issue25083@psf.upfronthosting.co.za>


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

I'm un-cc'ing myself as I don't use Python 2 in an environment where we allow it to write .pyc files at application runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Sat Oct 21 16:33:23 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Oct 2017 20:33:23 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508618003.12.0.213398074469.issue25083@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Sat Oct 21 19:25:15 2017
From: report at bugs.python.org (Mauro)
Date: Sat, 21 Oct 2017 23:25:15 +0000
Subject: [issue31838] Python 3.4 supported SSL version
Message-ID: <1508628315.52.0.213398074469.issue31838@psf.upfronthosting.co.za>


New submission from Mauro <fontana.mauro at gmail.com>:

Hello and sorry to bother. This is my first message to the list.

I'm trying to build python 3.4.7 downloaded from python.org (released in August this year) and while following the exact same steps detailed in  https://bugs.python.org/issue29027, I get getting the exact same error he does.

Doesn't Python 3.4 support OpenSSL v 1.1.0? Is this is the case, I guess it will never do, right?

More importantly, is there a place to get build dependencies (with appropriate versions) for each CPython version? I scrawled the source and the GitHub repositories without luck.

I guess this has been asked before, but after several hours, I couldn't find anything.

Cheers,
Mauro

----------
assignee: christian.heimes
components: SSL
messages: 304725
nosy: christian.heimes, sabian2008
priority: normal
severity: normal
status: open
title: Python 3.4 supported SSL version
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31838>
_______________________________________

From report at bugs.python.org  Sat Oct 21 20:48:13 2017
From: report at bugs.python.org (calimeroteknik)
Date: Sun, 22 Oct 2017 00:48:13 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
Message-ID: <1508633293.0.0.213398074469.issue31831@psf.upfronthosting.co.za>


calimeroteknik <calimeroteknik at free.fr> added the comment:

Eventually there is no bug, I was just confused at the output of print() on the EmailMessage.

I noticed that in email/_header_value_parser.py policy.utf8 was True.
The reason is found in email/message.py line 970 (class MIMEPart):

    def __str__(self):
       	return self.as_string(policy=self.policy.clone(utf8=True)

print() will use __str__() and this is why it happens.

I didn't dig out the exact reason since there are so many delegated calls.
In any case, the flattened message in smtplib.SMTP does contain what as_string() returns, which means that the policy.utf8 is only forced when using print().

Sorry for the false alert.
I can guess that the intention in forcing policy.utf8=True in __str__() was that SMTPUTF8 output is visually prettier than any ASCII-armored text.

After additional fuzzing, checking the output with EmailMessage.as_string(), everything seems OK.

That's a +1 for gh-3488, which fixes this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Sat Oct 21 22:55:52 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Oct 2017 02:55:52 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508640952.55.0.213398074469.issue25083@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Adding a couple of Red Hat folks to the nosy list, as even though this was originally reported for Windows, the reproducers show that it's a cross-platform issue.

tzickel would you mind signing the Python CLA and turning your patch into a PR on Github?

----------
nosy: +cstratak, encukou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Sun Oct 22 00:56:08 2017
From: report at bugs.python.org (Oren Tirosh)
Date: Sun, 22 Oct 2017 04:56:08 +0000
Subject: [issue31839] datetime: add method to parse isoformat() output
Message-ID: <1508648168.49.0.213398074469.issue31839@psf.upfronthosting.co.za>


New submission from Oren Tirosh <orent at hishome.net>:

The object types in the datetime module can produce a standard string representation (rfc3339, a subset of iso8601) but they do not provide a method to parse it.

Proposed method names: isoparse or fromisoformat.

In addition, a constructor call with a single string argument may also be supported. This would make the behavior of datetime/date/time more similar to other value types such as int, str or float and maintain the same invariant of x == type(x)(str(x))

Requirements: support lossless round-tripping of all valid datetime object values to str and back, with the exception of objects having a custom tzinfo (not None or an instance of datetime.timezone).

The _strptime format of '%Y-%m-%d %H:%M:S.%f%z' comes close, but fails to meet these requirements in the following ways:

1. %z matches +HHMM, not +HH:MM (addressed by issue 31800, currently discussed on datetime-sig)
2. %z does not match the empty string, indicating a naive datetime object (tzinfo=None)
3. .%f requires a fraction part, while isoformat drops it when the timestamp is an exact second (microsecond=0).

----------
messages: 304728
nosy: orent
priority: normal
severity: normal
status: open
title: datetime: add method to parse isoformat() output
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31839>
_______________________________________

From report at bugs.python.org  Sun Oct 22 02:06:57 2017
From: report at bugs.python.org (=?utf-8?b?SGlyb2tpIOKAnGgy4oCdIEhvcml1Y2hp?=)
Date: Sun, 22 Oct 2017 06:06:57 +0000
Subject: [issue31840] `ImportError` is` raised` only when `python -m unittest
 discover` is given
Message-ID: <1508652417.45.0.213398074469.issue31840@psf.upfronthosting.co.za>


New submission from Hiroki ?h2? Horiuchi <x19290 at gmail.com>:

Create a package `pkg`. Put `test.py` there. Write `none = None` in `pkg/__init__.py`.
In the directory containing `pkg/`, `python [23] -m unittest pkg.test` will terminate normally, but `python [23] -m unittest discover pkg` will raise `ImportError`. The phenomenon is the same in macOS Sierra, Debian 9.0, Windows 7. I do not think this is a very kind behavior.
Thank you.

----------
components: Library (Lib), Tests, Windows, macOS
files: test.py
messages: 304729
nosy: Hiroki ?h2? Horiuchi, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: `ImportError` is` raised` only when `python -m unittest discover` is given
type: behavior
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file47230/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31840>
_______________________________________

From report at bugs.python.org  Sun Oct 22 02:26:47 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Oct 2017 06:26:47 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508653607.32.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I rewrote the PEP based on the latest iteration of the design concept: https://github.com/python/peps/commit/9a8e590a523bdeed0598084a0782fb07fc15dfc0

(That initial commit has some minor errors in it that I've already fixed, so check the latest version in the repo if you spot anything else - if I'd thought it through properly, I would have submitted the update as a PR, so folks had a place to more easily make line-by-line comments)

I genuinely like this version, and I think it should be reasonably straightforward to implement (given that types.MappingProxyType already exists).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 22 02:30:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 06:30:25 +0000
Subject: [issue31840] `ImportError` is` raised` only when `python -m unittest
 discover` is given
In-Reply-To: <1508652417.45.0.213398074469.issue31840@psf.upfronthosting.co.za>
Message-ID: <1508653825.51.0.213398074469.issue31840@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Run

    python -m unittest discover --start-directory pkg --top-level-directory .

By default the top level directory is the same as the start directory (i.e. pkg).

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31840>
_______________________________________

From report at bugs.python.org  Sun Oct 22 03:34:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 07:34:48 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1508657688.96.0.213398074469.issue26765@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26765>
_______________________________________

From report at bugs.python.org  Sun Oct 22 03:40:26 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 07:40:26 +0000
Subject: [issue16700] Document that bytes OS API can returns unusable results
 on Windows
In-Reply-To: <1355677117.39.0.191453655217.issue16700@psf.upfronthosting.co.za>
Message-ID: <1508658026.75.0.213398074469.issue16700@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16700>
_______________________________________

From report at bugs.python.org  Sun Oct 22 03:52:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 07:52:54 +0000
Subject: [issue16700] Document that bytes OS API can returns unusable results
 on Windows
In-Reply-To: <1355677117.39.0.191453655217.issue16700@psf.upfronthosting.co.za>
Message-ID: <1508658774.67.0.213398074469.issue16700@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is now 2.7 only issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16700>
_______________________________________

From report at bugs.python.org  Sun Oct 22 03:59:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 07:59:05 +0000
Subject: [issue28022] SSL releated deprecation for 3.6
In-Reply-To: <1473347942.69.0.310193437319.issue28022@psf.upfronthosting.co.za>
Message-ID: <1508659145.33.0.213398074469.issue28022@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Shouldn't this issue be closed?

Since SSL context arguments are not supported in 2.7, the deprecated arguments can't be removed until EOL of 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28022>
_______________________________________

From report at bugs.python.org  Sun Oct 22 04:11:30 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 08:11:30 +0000
Subject: [issue28197] range.index mismatch with documentation
In-Reply-To: <1474231832.91.0.157673750963.issue28197@psf.upfronthosting.co.za>
Message-ID: <1508659890.99.0.213398074469.issue28197@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28197>
_______________________________________

From report at bugs.python.org  Sun Oct 22 04:14:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 08:14:32 +0000
Subject: [issue24567] random.choice IndexError due to double-rounding
In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za>
Message-ID: <1508660072.88.0.213398074469.issue24567@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a pull request Raymond?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24567>
_______________________________________

From report at bugs.python.org  Sun Oct 22 04:23:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 08:23:04 +0000
Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in
 edge cases
In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>
Message-ID: <1508660584.24.0.213398074469.issue28292@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a pull request Alexander?

----------
components: +Library (Lib)
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28292>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:06:46 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 09:06:46 +0000
Subject: [issue28326] multiprocessing.Process depends on sys.stdout being open
In-Reply-To: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za>
Message-ID: <1508663206.62.0.213398074469.issue28326@psf.upfronthosting.co.za>


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


----------
pull_requests: +4043

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28326>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:13:17 2017
From: report at bugs.python.org (Koos Zevenhoven)
Date: Sun, 22 Oct 2017 09:13:17 +0000
Subject: [issue31815] Make itertools iterators interruptible
In-Reply-To: <1508344981.58.0.213398074469.issue31815@psf.upfronthosting.co.za>
Message-ID: <1508663597.65.0.213398074469.issue31815@psf.upfronthosting.co.za>


Koos Zevenhoven <k7hoven at gmail.com> added the comment:

For the interactive user who uses an interactive environment such as the repl or a Jupyter notebook, the situation is a little different from "CPython as programming language runtime".

The docs say a KeyboardInterrupt is "Raised when the user hits the interrupt key (normally Control-C or Delete). During execution, a check for interrupts is made regularly.". I suppose there's some ambiguity in what "regularly" means there ;). 

But regardless of whether anyone bothers to read that part of the docs, Ctrl-C or an interrupt button not working can feel like a correctness issue for someone that's using an interactive Python environment *as an application* in daily work. Python gives you the impression that you can always interrupt anything if it turns out to take too much time. And I remember that being one of the points that made me move away from matlab, which at that time had problems with interrupting computations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31815>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:37:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 09:37:32 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508665052.63.0.213398074469.issue28286@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4044

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:40:33 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 09:40:33 +0000
Subject: [issue28326] multiprocessing.Process depends on sys.stdout being open
In-Reply-To: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za>
Message-ID: <1508665233.51.0.213398074469.issue28326@psf.upfronthosting.co.za>


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


New changeset daeefd2e049b74340307481112a39f77de0f4769 by Antoine Pitrou in branch 'master':
bpo-28326: Fix multiprocessing.Process when stdout and/or stderr is closed or None. (#4073)
https://github.com/python/cpython/commit/daeefd2e049b74340307481112a39f77de0f4769


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28326>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:46:42 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 09:46:42 +0000
Subject: [issue28326] multiprocessing.Process depends on sys.stdout being open
In-Reply-To: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za>
Message-ID: <1508665602.55.0.213398074469.issue28326@psf.upfronthosting.co.za>


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


----------
pull_requests: +4045

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28326>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:47:59 2017
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 22 Oct 2017 09:47:59 +0000
Subject: [issue31838] Python 3.4 supported SSL version
In-Reply-To: <1508628315.52.0.213398074469.issue31838@psf.upfronthosting.co.za>
Message-ID: <1508665679.6.0.213398074469.issue31838@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

You are correct, Python 3.4 does not support OpenSSL 1.1 and will never support it.

The last bug fix release of Python 3.4 was 3.4.4 in 2015-12-20. 3.4.5 and newer are security fix releases that only contain critical security updates. OpenSSL 1.1.0 was released 2016-08-25, about 9 months after Python 3.4 reached security-only mode.

We have a repository for Windows source dependencies: https://github.com/python/cpython-source-deps. It's not meant for general consumption.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31838>
_______________________________________

From report at bugs.python.org  Sun Oct 22 05:52:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 09:52:51 +0000
Subject: [issue28416] defining persistent_id in _pickle.Pickler subclass
 causes reference cycle
In-Reply-To: <1476202451.78.0.408768500752.issue28416@psf.upfronthosting.co.za>
Message-ID: <1508665971.3.0.213398074469.issue28416@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28416>
_______________________________________

From report at bugs.python.org  Sun Oct 22 06:18:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 10:18:23 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508667503.29.0.213398074469.issue28286@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bcbdd2f8db396c3f0ec9186162b39b5a34effa0e by Serhiy Storchaka in branch 'master':
bpo-28286: Add tests for the mode argument of GzipFile. (#4074)
https://github.com/python/cpython/commit/bcbdd2f8db396c3f0ec9186162b39b5a34effa0e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 06:18:30 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Oct 2017 10:18:30 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508667510.56.0.213398074469.issue28286@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4046

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 06:27:15 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 10:27:15 +0000
Subject: [issue28326] multiprocessing.Process depends on sys.stdout being open
In-Reply-To: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za>
Message-ID: <1508668035.88.0.213398074469.issue28326@psf.upfronthosting.co.za>


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


New changeset 34ef6da8f5fb03b83268bd35b77fb2183c748b70 by Antoine Pitrou in branch '3.6':
[3.6] bpo-28326: Fix multiprocessing.Process when stdout and/or stderr is closed or None. (GH-4073).  (#4075)
https://github.com/python/cpython/commit/34ef6da8f5fb03b83268bd35b77fb2183c748b70


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28326>
_______________________________________

From report at bugs.python.org  Sun Oct 22 06:27:53 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 10:27:53 +0000
Subject: [issue28326] multiprocessing.Process depends on sys.stdout being open
In-Reply-To: <1475322334.82.0.360171618996.issue28326@psf.upfronthosting.co.za>
Message-ID: <1508668073.61.0.213398074469.issue28326@psf.upfronthosting.co.za>


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

This is now fixed in 3.6 and 3.7.  Closing!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28326>
_______________________________________

From report at bugs.python.org  Sun Oct 22 06:43:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 10:43:34 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508669014.53.0.213398074469.issue28286@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4047

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 06:45:33 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 10:45:33 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1508669133.12.0.213398074469.issue31653@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4048
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Sun Oct 22 07:10:50 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 11:10:50 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1508670650.25.0.213398074469.issue31653@psf.upfronthosting.co.za>


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


New changeset c872d39d324cd6f1a71b73e10406bbaed192d35f by Antoine Pitrou in branch 'master':
bpo-31653: Don't release the GIL if we can acquire a multiprocessing semaphore immediately (#4078)
https://github.com/python/cpython/commit/c872d39d324cd6f1a71b73e10406bbaed192d35f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Sun Oct 22 07:11:08 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 11:11:08 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1508670668.03.0.213398074469.issue31653@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Sun Oct 22 07:53:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 11:53:46 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508673226.35.0.213398074469.issue28286@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 251de30935490a702b0a365f1e9bea696b39c016 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-28286: Add tests for the mode argument of GzipFile. (GH-4074) (#4076)
https://github.com/python/cpython/commit/251de30935490a702b0a365f1e9bea696b39c016


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 07:54:07 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 11:54:07 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508673247.61.0.213398074469.issue28286@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f7d19b0464cb89ec696affbad9fd7e7c94456eaf by Serhiy Storchaka in branch '2.7':
[2.7] bpo-28286: Add tests for the mode argument of GzipFile. (GH-4074). (#4077)
https://github.com/python/cpython/commit/f7d19b0464cb89ec696affbad9fd7e7c94456eaf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 08:06:24 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 Oct 2017 12:06:24 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508673984.06.0.213398074469.issue30744@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Nick, in msg304388 you wrote "[allow] immediate write-through from trace functions". The latest iteration of PEP 558 says instead:

"tracing mode: the way the interpreter behaves when a trace hook has been registered..."

and also says:

"As long as the process remains in tracing mode, then __setitem__ and __delitem__ operations on the proxy will affect not only the dynamic snapshot, but also the corresponding fast local or cell reference on the underlying frame."

So write-through is allowed by the current PEP outside a trace function. Does not this change in some cases the behavior of code that updates the mapping returned by locals() when tracing mode is active from its standard behavior when there is no tracing ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 22 08:20:02 2017
From: report at bugs.python.org (SilentGhost)
Date: Sun, 22 Oct 2017 12:20:02 +0000
Subject: [issue31839] datetime: add method to parse isoformat() output
In-Reply-To: <1508648168.49.0.213398074469.issue31839@psf.upfronthosting.co.za>
Message-ID: <1508674802.74.0.213398074469.issue31839@psf.upfronthosting.co.za>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +belopolsky
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31839>
_______________________________________

From mal at egenix.com  Sun Oct 22 08:39:05 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 22 Oct 2017 14:39:05 +0200
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508521608.25.0.213398074469.issue31803@psf.upfronthosting.co.za>
References: <1508521608.25.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <cf2bb815-fe6c-dbad-7b90-3b188f4415ee@egenix.com>

On 20.10.2017 19:46, Serhiy Storchaka wrote:
> 
> This will break a code that depends on the current behavior on non-Windows platforms. And this will contradict the expectation of non-Windows programmers. If change the behavior of clock() on non-Windows platforms, it should be done only after the period of emitting FutureWarning.

Could you explain which behavior is changed by this on non-Windows
platforms ?

time.clock() only switches to a more accurate clock. That's pretty
much it. Which clock it used on which platform was platform
dependent anyway, so there's no real change in behavior.

For benchmarking and other measurements, time.time() was recommended
on Unix and time.clock() on Windows. time.clock() never good
resolution on Unix, so the situation only improves by using
a more accurate clock.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Sun Oct 22 08:39:09 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 22 Oct 2017 12:39:09 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508521608.25.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <cf2bb815-fe6c-dbad-7b90-3b188f4415ee@egenix.com>


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

On 20.10.2017 19:46, Serhiy Storchaka wrote:
> 
> This will break a code that depends on the current behavior on non-Windows platforms. And this will contradict the expectation of non-Windows programmers. If change the behavior of clock() on non-Windows platforms, it should be done only after the period of emitting FutureWarning.

Could you explain which behavior is changed by this on non-Windows
platforms ?

time.clock() only switches to a more accurate clock. That's pretty
much it. Which clock it used on which platform was platform
dependent anyway, so there's no real change in behavior.

For benchmarking and other measurements, time.time() was recommended
on Unix and time.clock() on Windows. time.clock() never good
resolution on Unix, so the situation only improves by using
a more accurate clock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Sun Oct 22 09:14:36 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 13:14:36 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508678076.34.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

On non-Windows platforms clock() returns the processor time, perf_counter() does include time elapsed during sleep.

>>> import time
>>> start = time.clock(); time.sleep(1); print(time.clock() - start)
9.700000000001374e-05
>>> start = time.perf_counter(); time.sleep(1); print(time.perf_counter() - start)
1.000714950998372

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Sun Oct 22 09:16:24 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 22 Oct 2017 13:16:24 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508678076.34.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <0545c552-ead0-c26e-2ea1-8a969154fc71@egenix.com>


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

On 22.10.2017 15:14, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
> 
> On non-Windows platforms clock() returns the processor time, perf_counter() does include time elapsed during sleep.
> 
>>>> import time
>>>> start = time.clock(); time.sleep(1); print(time.clock() - start)
> 9.700000000001374e-05
>>>> start = time.perf_counter(); time.sleep(1); print(time.perf_counter() - start)
> 1.000714950998372

Thanks for pointing that out. I didn't know.

Is there a different clock with similar accuracy we can use
to only count CPU time on Unix ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Sun Oct 22 09:38:15 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 13:38:15 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508679495.93.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is time.process_time(). This was the cause of adding two new functions time.perf_counter() and time.process_time() and deprecating (in the documentation only) time.clock(). On Windows time.clock() does include time elapsed during sleep, on non-Windows it doesn't. time.clock() should be replaced with the one of these functions, depending on the purpose of its use. Only the user knows for what purposes it uses time.clock() and what is the correct replacement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Sun Oct 22 09:44:23 2017
From: report at bugs.python.org (Mauro Fontana)
Date: Sun, 22 Oct 2017 13:44:23 +0000
Subject: [issue31838] Python 3.4 supported SSL version
In-Reply-To: <1508628315.52.0.213398074469.issue31838@psf.upfronthosting.co.za>
Message-ID: <1508679863.16.0.213398074469.issue31838@psf.upfronthosting.co.za>


Mauro Fontana <fontana.mauro at gmail.com> added the comment:

Hi Christian

Great! Thanks for the information.

I apologize if this was trivial, just wanted to make sure.

Cheers,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31838>
_______________________________________

From report at bugs.python.org  Sun Oct 22 09:44:40 2017
From: report at bugs.python.org (Mauro Fontana)
Date: Sun, 22 Oct 2017 13:44:40 +0000
Subject: [issue31838] Python 3.4 supported SSL version
In-Reply-To: <1508628315.52.0.213398074469.issue31838@psf.upfronthosting.co.za>
Message-ID: <1508679880.97.0.213398074469.issue31838@psf.upfronthosting.co.za>


Change by Mauro Fontana <fontana.mauro at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31838>
_______________________________________

From report at bugs.python.org  Sun Oct 22 10:27:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 14:27:41 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508682461.03.0.213398074469.issue31752@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Unpatched Python should crash in debug build and can raise SystemError in release build.

I can't reproduce a crash on Windows after the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Sun Oct 22 10:41:21 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 14:41:21 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508683281.13.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sun Oct 22 11:03:22 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Oct 2017 15:03:22 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508684602.63.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, as locals() never returns the write-through proxy in the latest version of the PEP - it only ever returns the dynamic snapshot namespace (retrieving it from the proxy if necessary).

To get access to the write-through proxy in Python level code, you have to access frame.f_locals directly (which trace functions will do by necessity, since that's the only way they have to get at the function locals).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 22 11:08:52 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Oct 2017 15:08:52 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1508684932.01.0.213398074469.issue30744@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

When I rejected that approach previously, it hadn't occurred to me yet that the write-through proxy could write through to both the frame state *and* the regular dynamic snapshot returned by locals().

The current design came from asking myself "What if the proxied reads always came from the snapshot, just like they do now, but writes went to *both* places?".

So far I haven't found any fundamental problems with the approach, but I also haven't implemented it yet - I've only read through all the places in the code where I think I'm going to have to make changes in order to get it to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sun Oct 22 11:26:19 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 Oct 2017 15:26:19 +0000
Subject: [issue28224] Compilation warnings on Windows: export 'PyInit_xx'
 specified multiple times
In-Reply-To: <1474442469.56.0.286518199442.issue28224@psf.upfronthosting.co.za>
Message-ID: <1508685979.9.0.213398074469.issue28224@psf.upfronthosting.co.za>


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

I know I closed #20166 myself, but could we revisit this?

I'm now in favor of telling people to fix their modules.

----------
nosy: +skrah
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28224>
_______________________________________

From report at bugs.python.org  Sun Oct 22 12:03:15 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 16:03:15 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508688195.04.0.213398074469.issue31835@psf.upfronthosting.co.za>


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


----------
nosy: +haypo
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Sun Oct 22 12:27:10 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Oct 2017 16:27:10 +0000
Subject: =?utf-8?q?=5Bissue31831=5D_EmailMessage=2Eadd=5Fattachment=28filename=3D?=
 =?utf-8?q?=22long_or_sp=C3=A9cial=22=29_crashes_or_produces_invalid_outpu?=
 =?utf-8?q?t?=
In-Reply-To: <1508538176.94.0.213398074469.issue31831@psf.upfronthosting.co.za>
Message-ID: <1508689630.12.0.213398074469.issue31831@psf.upfronthosting.co.za>


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

Great, thank you for that research.  And yes, that's exactly why __str__ uses utf8=True, the "picture" of the message is much more readable.  I will commit that PR soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31831>
_______________________________________

From report at bugs.python.org  Sun Oct 22 13:49:38 2017
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Sun, 22 Oct 2017 17:49:38 +0000
Subject: [issue31828] Support Py_tss_NEEDS_INIT outside of static
 initialisation
In-Reply-To: <1508515676.46.0.213398074469.issue31828@psf.upfronthosting.co.za>
Message-ID: <1508694578.56.0.213398074469.issue31828@psf.upfronthosting.co.za>


Masayuki Yamamoto <ma3yuki.8mamo10 at gmail.com> added the comment:

Or Py_tss_NEEDS_INIT is removed from the C API document to become a private feature; in other words, the Python interpreter will recommend that the static allocation for the TSS key shouldn't be used in the API client codes except for the interpreter core and built-in modules. (okay, I know it's an unfair suggestion)

BTW, it's my mistake which the word "default value" for Py_tss_NEEDS_INIT, actually it makes more sense "initializer". I'd like to fix the document and the PEP, would I open the PR with this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31828>
_______________________________________

From report at bugs.python.org  Sun Oct 22 14:26:00 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Oct 2017 18:26:00 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1508696760.31.0.213398074469.issue31836@psf.upfronthosting.co.za>


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

On the PR, Serhiy asks "Wouldn't be better to restore sys.ps1 in test_idle if it is changed here?"

Aside from the fact that, as far as I know, it is not sanely possible to do so, I think it a bug for a test to be unnecessarily fragile.  Both ps1 and ps2 are set when Python is in interactive mode.  IDLE is only (partially) imitating Python's shell when it sets sys.ps1.

The premise of #25588 is that tests should accommodate sys.stdout and sys.stderr being None to the extent possible.  I think the same applies to sys.ps1/2 being set.  Indeed, as I reported on #31761, in msg304298, 9 days ago, test_code_module tests test_ps1 and test_ps2 failed when I ran '>>> import test.autotest' in a *Python* shell.  I did not understand the reason for the failures then, but if I had investigated, I should hope that I would have submitted the same PR, which fixes this autotest failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sun Oct 22 14:31:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Oct 2017 18:31:37 +0000
Subject: [issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()
In-Reply-To: <1506275205.91.0.662869765666.issue31572@psf.upfronthosting.co.za>
Message-ID: <1508697097.15.0.213398074469.issue31572@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 04e36af9b88cd5e80fc818e51d46f07252a2ff3f by Serhiy Storchaka in branch 'master':
bpo-31572: Get rid of using _PyObject_HasAttrId() in pickle. (#3729)
https://github.com/python/cpython/commit/04e36af9b88cd5e80fc818e51d46f07252a2ff3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31572>
_______________________________________

From report at bugs.python.org  Sun Oct 22 15:32:33 2017
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 22 Oct 2017 19:32:33 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1508700753.06.0.213398074469.issue25612@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Thanks Serhiy for spotting that.

'raise' should raise the same exception as sys.exc_info() returns.
I'll update the PR.

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Sun Oct 22 15:46:35 2017
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 22 Oct 2017 19:46:35 +0000
Subject: [issue31841] Several methods of collections.UserString do not return
 instances of UserString or its subclasses
Message-ID: <1508701595.06.0.213398074469.issue31841@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov <waultah at gmail.com>:

A few of the methods of collections.UserString return objects of type str when one would expect instances of UserString or a subclass. Here's an example for UserString.join:

    >>> s = UserString(', ').join(['a', 'b', 'c']); print(repr(s), type(s))
    'a, b, c' <class 'str'>

This *looks* like a bug to me, but since I was unable to find similar bug reports, and this behaviour has existed for years, I'm not too sure.

Same holds for UserString.format and UserString.format_map, which were added recently (issue 22189):

    >>> s = UserString('{}').format(1); print(repr(s), type(s))
    '1' <class 'str'>

At least, this output is inconsistent with %-based formatting:

    >>> s = UserString('%d') % 1; print(repr(s), type(s))
    '1' <class 'collections.UserString'>

----------
components: Library (Lib)
messages: 304761
nosy: vaultah
priority: normal
severity: normal
status: open
title: Several methods of collections.UserString do not return instances of UserString or its subclasses
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31841>
_______________________________________

From report at bugs.python.org  Sun Oct 22 16:19:14 2017
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 22 Oct 2017 20:19:14 +0000
Subject: [issue28286] gzip guessing of mode is ambiguous
In-Reply-To: <1474984904.89.0.353695342219.issue28286@psf.upfronthosting.co.za>
Message-ID: <1508703554.04.0.213398074469.issue28286@psf.upfronthosting.co.za>


Change by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28286>
_______________________________________

From report at bugs.python.org  Sun Oct 22 16:22:30 2017
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 22 Oct 2017 20:22:30 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1508703750.25.0.213398074469.issue31756@psf.upfronthosting.co.za>


Change by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Sun Oct 22 16:32:54 2017
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 22 Oct 2017 20:32:54 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1508704374.39.0.213398074469.issue14465@psf.upfronthosting.co.za>


Change by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Sun Oct 22 16:34:58 2017
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 22 Oct 2017 20:34:58 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1508704498.03.0.213398074469.issue31756@psf.upfronthosting.co.za>


Change by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy:  -wolma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:18:50 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Oct 2017 21:18:50 +0000
Subject: [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1508707130.95.0.213398074469.issue9842@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Since the appearance of reprs is not guaranteed.  I don't think this should be documented (because doing so makes it a guaranteed behavior).  In fact, the appearance has changed over time from ... to  [...] in and may change at some point to <...> so that it can't be confused with an actual Ellipsis object.  At best this should be a FAQ entry or we can defer to behaviors that are documented and guaranteed (such as reprlib.recursive_repr() and its default fillvalue).  

I concur with David Murray that the Ellipsis object should be indexed and cross-referenced.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9842>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:26:10 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Oct 2017 21:26:10 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1508707570.77.0.213398074469.issue31826@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would support just removing the version attributes for csv and re.

----------
nosy: +ncoghlan, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:26:37 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:26:37 +0000
Subject: [issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()
In-Reply-To: <1506275205.91.0.662869765666.issue31572@psf.upfronthosting.co.za>
Message-ID: <1508707597.15.0.213398074469.issue31572@psf.upfronthosting.co.za>


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

> The only solution of this problem is getting rid of PyObject_HasAttr() if favor of PyObject_GetAttr().

I don't understand why.  Why not fix PyObject_HasAttr() like hasattr() was?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31572>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:27:44 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:27:44 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1508707664.29.0.213398074469.issue31826@psf.upfronthosting.co.za>


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

+1 for removing __version__ on all stdlib modules which are not externally maintained.

----------
nosy: +pitrou
versions:  -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:28:01 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Oct 2017 21:28:01 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1508707681.39.0.213398074469.issue31739@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Lisa, would you care to wrap this one up?

----------
assignee: docs at python -> lisroach
nosy: +lisroach, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:28:55 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Oct 2017 21:28:55 +0000
Subject: [issue31822] Document that urllib.parse.{Defrag, Split,
 Parse}Result are namedtuples
In-Reply-To: <1508439273.05.0.213398074469.issue31822@psf.upfronthosting.co.za>
Message-ID: <1508707735.23.0.213398074469.issue31822@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> lisroach
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:31:13 2017
From: report at bugs.python.org (Erik Aronesty)
Date: Sun, 22 Oct 2017 21:31:13 +0000
Subject: [issue31842] pathlib: "Incorrect function" during resolve()
Message-ID: <1508707873.05.0.213398074469.issue31842@psf.upfronthosting.co.za>


New submission from Erik Aronesty <earonesty at gmail.com>:

When strict is "false", pathlib should not fail if the network share is inaccessible.  It should, as documented, catch the exception and continue with as much of the path as it has.



>>> pathlib.Path("v:").resolve()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\erik\AppData\Local\Programs\Python\Python36\lib\pathlib.py", line 1119, in resolve
    s = self._flavour.resolve(self, strict=strict)
  File "C:\Users\erik\AppData\Local\Programs\Python\Python36\lib\pathlib.py", line 193, in resolve
    s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1] Incorrect function: 'v:'

----------
messages: 304767
nosy: earonesty2
priority: normal
severity: normal
status: open
title: pathlib: "Incorrect function" during resolve()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31842>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:31:34 2017
From: report at bugs.python.org (Erik Aronesty)
Date: Sun, 22 Oct 2017 21:31:34 +0000
Subject: [issue31842] pathlib: "Incorrect function" during resolve()
In-Reply-To: <1508707873.05.0.213398074469.issue31842@psf.upfronthosting.co.za>
Message-ID: <1508707894.21.0.213398074469.issue31842@psf.upfronthosting.co.za>


Change by Erik Aronesty <earonesty at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31842>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:39:51 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:39:51 +0000
Subject: [issue20825] containment test for "ip_network in ip_network"
In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
Message-ID: <1508708391.96.0.213398074469.issue20825@psf.upfronthosting.co.za>


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


New changeset 91dc64ba3f51100540b2ab6c6cd72c3bb18a6d49 by Antoine Pitrou (Cheryl Sabella) in branch 'master':
bpo-20825: Containment test for ip_network in ip_network.
https://github.com/python/cpython/commit/91dc64ba3f51100540b2ab6c6cd72c3bb18a6d49


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20825>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:40:44 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:40:44 +0000
Subject: [issue20825] containment test for "ip_network in ip_network"
In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za>
Message-ID: <1508708444.03.0.213398074469.issue20825@psf.upfronthosting.co.za>


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

This is now in 3.7.  Thanks to everyone who contributed!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20825>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:41:53 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:41:53 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1508708513.83.0.213398074469.issue25612@psf.upfronthosting.co.za>


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


New changeset ae3087c6382011c47db82fea4d05f8bbf514265d by Antoine Pitrou (Mark Shannon) in branch 'master':
Move exc state to generator. Fixes bpo-25612 (#1773)
https://github.com/python/cpython/commit/ae3087c6382011c47db82fea4d05f8bbf514265d


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:42:57 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:42:57 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1508708577.56.0.213398074469.issue25612@psf.upfronthosting.co.za>


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

Thank you Mark for the fix!

----------
versions:  -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Sun Oct 22 17:53:31 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Oct 2017 21:53:31 +0000
Subject: [issue31833] Compile fail on gentoo for MIPS CPU of loongson 2f
In-Reply-To: <1508560342.69.0.213398074469.issue31833@psf.upfronthosting.co.za>
Message-ID: <1508709211.28.0.213398074469.issue31833@psf.upfronthosting.co.za>


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

You should try running with strace to see which system call failed:

$ strace ./python -c "import _multiprocessing"

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31833>
_______________________________________

From report at bugs.python.org  Sun Oct 22 20:13:45 2017
From: report at bugs.python.org (Allen Li)
Date: Mon, 23 Oct 2017 00:13:45 +0000
Subject: [issue31843] sqlite3.connect() should accept PathLike objects
Message-ID: <1508717625.1.0.213398074469.issue31843@psf.upfronthosting.co.za>


New submission from Allen Li <vianchielfaura at gmail.com>:

sqlite3.connect() should accept PathLike objects (objects that implement __fspath__)

----------
messages: 304773
nosy: Allen Li
priority: normal
severity: normal
status: open
title: sqlite3.connect() should accept PathLike objects
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31843>
_______________________________________

From report at bugs.python.org  Sun Oct 22 20:13:55 2017
From: report at bugs.python.org (Allen Li)
Date: Mon, 23 Oct 2017 00:13:55 +0000
Subject: [issue31843] sqlite3.connect() should accept PathLike objects
In-Reply-To: <1508717625.1.0.213398074469.issue31843@psf.upfronthosting.co.za>
Message-ID: <1508717635.92.0.213398074469.issue31843@psf.upfronthosting.co.za>


Change by Allen Li <vianchielfaura at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31843>
_______________________________________

From report at bugs.python.org  Sun Oct 22 22:01:22 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 Oct 2017 02:01:22 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1508724082.29.0.213398074469.issue31756@psf.upfronthosting.co.za>


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


New changeset 7fed7bd8bb628f0f09c6011871a4ce68afb41b18 by Gregory P. Smith (andyclegg) in branch 'master':
bpo-31756: subprocess.run should alias universal_newlines to text (#4049)
https://github.com/python/cpython/commit/7fed7bd8bb628f0f09c6011871a4ce68afb41b18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Sun Oct 22 22:03:49 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 Oct 2017 02:03:49 +0000
Subject: [issue31756] subprocess.run should alias universal_newlines to text
In-Reply-To: <1507717011.91.0.213398074469.issue31756@psf.upfronthosting.co.za>
Message-ID: <1508724229.66.0.213398074469.issue31756@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31756>
_______________________________________

From report at bugs.python.org  Sun Oct 22 22:10:31 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Oct 2017 02:10:31 +0000
Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in
 edge cases
In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>
Message-ID: <1508724631.15.0.213398074469.issue28292@psf.upfronthosting.co.za>


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

Let me look into this.  It's been a while ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28292>
_______________________________________

From report at bugs.python.org  Sun Oct 22 22:25:32 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Oct 2017 02:25:32 +0000
Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in
 edge cases
In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>
Message-ID: <1508725532.62.0.213398074469.issue28292@psf.upfronthosting.co.za>


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

> 1. Raise OverflowError at both ends (revert issue15421patch). The method becomes unusable for two extreme months.

The issue 15421 patch was committed in 85710a40e7e9eab86060bedc3762ccf9ca8d26ca.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28292>
_______________________________________

From report at bugs.python.org  Sun Oct 22 23:34:00 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Oct 2017 03:34:00 +0000
Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in
 edge cases
In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>
Message-ID: <1508729640.74.0.213398074469.issue28292@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4049
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28292>
_______________________________________

From report at bugs.python.org  Sun Oct 22 23:40:53 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Oct 2017 03:40:53 +0000
Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in
 edge cases
In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>
Message-ID: <1508730053.2.0.213398074469.issue28292@psf.upfronthosting.co.za>


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

I submitted PR 4079. Serhiy, please review the logic and if this matches what we discussed a year ago, I will add the docs and NEWS entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28292>
_______________________________________

From report at bugs.python.org  Sun Oct 22 23:53:17 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Oct 2017 03:53:17 +0000
Subject: [issue31828] Support Py_tss_NEEDS_INIT outside of static
 initialisation
In-Reply-To: <1508515676.46.0.213398074469.issue31828@psf.upfronthosting.co.za>
Message-ID: <1508730797.66.0.213398074469.issue31828@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the wording fix, since it's just a trivial docs update, we can go ahead and fix it without an issue reference from the PRs.

As far as the API goes, I do want to support "static Py_tss_t my_tss_key = Py_tss_NEEDS_INIT;" in third party extension modules, which is what the current API gives us.

The question is whether there's a reasonable compiler independent way to also support struct *assignment*, in addition to initialisation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31828>
_______________________________________

From report at bugs.python.org  Sun Oct 22 23:56:14 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Oct 2017 03:56:14 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1508730974.09.0.213398074469.issue31826@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 from me for dropping these, and noting which modules were affected in the Porting section of the 3.7 What's New (I'd be surprised if anyone was depending on them existing, but it doesn't hurt to mention it, and may help if someone is trying to figure out what changed)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Mon Oct 23 02:15:42 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 23 Oct 2017 06:15:42 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1508739342.87.0.213398074469.issue31826@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please do leave version in the decimal module where it has a precise meaning, tracking a particular version of the spec that was implemented and tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Mon Oct 23 04:17:31 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Mon, 23 Oct 2017 08:17:31 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1508746651.1.0.213398074469.issue26123@psf.upfronthosting.co.za>


Sebastian Rittau <srittau at rittau.biz> added the comment:

I take the liberty of closing this "wont fix". Changing the behaviour would most likely do more harm than good. If one of the maintainers disagrees, please reopen. :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26123>
_______________________________________

From report at bugs.python.org  Mon Oct 23 04:27:23 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Mon, 23 Oct 2017 08:27:23 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
Message-ID: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at rittau.biz>:

HTMLParser derives from _markupbase.ParserBase, which has the following method:

class HTMLParser:

    ...

    def error(self, message):
        raise NotImplementedError(
            "subclasses of ParserBase must override error()")

HTMLParser does not implement this method and the documentation for HTMLParser (https://docs.python.org/3.6/library/html.parser.html) does not mention that its sub-classes need to override it.

I am not sure whether this is a documentation omission, whether HTMLParser should provide an (empty?) implementation, or whether ParserBase should not raise a NotImplementedError (to make linters happy).

----------
messages: 304782
nosy: srittau
priority: normal
severity: normal
status: open
title: HTMLParser: undocumented not implemented method
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Mon Oct 23 04:29:10 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Mon, 23 Oct 2017 08:29:10 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1508747350.73.0.213398074469.issue31844@psf.upfronthosting.co.za>


Sebastian Rittau <srittau at rittau.biz> added the comment:

The quoted code above should have used ParserBase:

class ParserBase:

    ...

    def error(self, message):
        raise NotImplementedError(
            "subclasses of ParserBase must override error()")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:00:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 09:00:17 +0000
Subject: [issue26123] http.client status code constants incompatible with
 Python 3.4
In-Reply-To: <1452863403.25.0.433090378442.issue26123@psf.upfronthosting.co.za>
Message-ID: <1508749217.61.0.213398074469.issue26123@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Sebastian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26123>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:22:17 2017
From: report at bugs.python.org (Lam Yuen Hei)
Date: Mon, 23 Oct 2017 09:22:17 +0000
Subject: [issue31546] PyOS_InputHook is not called when waiting for input() in
 Windows
In-Reply-To: <1506010382.42.0.274746719926.issue31546@psf.upfronthosting.co.za>
Message-ID: <1508750537.05.0.213398074469.issue31546@psf.upfronthosting.co.za>


Lam Yuen Hei <lamyuenhei at gmail.com> added the comment:

As the fix seems simple, any chance this bug can be fixed in next python 3.6 maintenance release? It is the major roadblock for my application to upgrade to python 3.6. Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31546>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:23:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 09:23:33 +0000
Subject: [issue28416] defining persistent_id in _pickle.Pickler subclass
 causes reference cycle
In-Reply-To: <1476202451.78.0.408768500752.issue28416@psf.upfronthosting.co.za>
Message-ID: <1508750613.27.0.213398074469.issue28416@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4050
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28416>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:24:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 09:24:56 +0000
Subject: [issue28416] defining persistent_id in _pickle.Pickler subclass
 causes reference cycle
In-Reply-To: <1476202451.78.0.408768500752.issue28416@psf.upfronthosting.co.za>
Message-ID: <1508750696.62.0.213398074469.issue28416@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 4080 converts bound methods into unbound methods if possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28416>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:29:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 09:29:42 +0000
Subject: [issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()
In-Reply-To: <1506275205.91.0.662869765666.issue31572@psf.upfronthosting.co.za>
Message-ID: <1508750982.25.0.213398074469.issue31572@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

hasattr() can return True, False, or raise an exception. But PyObject_HasAttr() just returns an integer: 0 for False, not 0 for True. There is no way to return an error, and existing code doesn't expect that PyObject_HasAttr() returns an error. Leaking an exception from PyObject_HasAttr() will break existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31572>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:32:53 2017
From: report at bugs.python.org (Josh Cullum)
Date: Mon, 23 Oct 2017 09:32:53 +0000
Subject: [issue31817] Compilation Error with Python 3.6.1/3.6.3 with Tkinter
In-Reply-To: <1508407674.96.0.213398074469.issue31817@psf.upfronthosting.co.za>
Message-ID: <1508751173.39.0.213398074469.issue31817@psf.upfronthosting.co.za>


Josh Cullum <joshua.cullum at gmail.com> added the comment:

Hi Ned,

Please see the make logs for _tkinter below:

building '_tkinter' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -fprofile-generate -DWITH_APPINIT=1 -I./Include -I. -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/tools/src/Python-3.6.3/Include -I/tools/src/Python-3.6.3 -c /tools/src/Python-3.6.3/Modules/_tkinter.c -o build/temp.linux-x86_64-3.6/tools/src/Python-3.6.3/Modules/_tkinter.o -I/tools/apps/tcl/8.6.7/include -I/tools/apps/tk/8.6.7/include
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -fprofile-generate -DWITH_APPINIT=1 -I./Include -I. -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/tools/src/Python-3.6.3/Include -I/tools/src/Python-3.6.3 -c /tools/src/Python-3.6.3/Modules/tkappinit.c -o build/temp.linux-x86_64-3.6/tools/src/Python-3.6.3/Modules/tkappinit.o -I/tools/apps/tcl/8.6.7/include -I/tools/apps/tk/8.6.7/include
gcc -pthread -shared -fprofile-generate -fprofile-generate build/temp.linux-x86_64-3.6/tools/src/Python-3.6.3/Modules/_tkinter.o build/temp.linux-x86_64-3.6/tools/src/Python-3.6.3/Modules/tkappinit.o -L. -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib -lpython3.6m -o build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu.so -L/tools/apps/tcl/8.6.7/lib -L/tools/apps/tk/8.6.7/lib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31817>
_______________________________________

From report at bugs.python.org  Mon Oct 23 05:59:34 2017
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Mon, 23 Oct 2017 09:59:34 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1508752774.78.0.213398074469.issue27645@psf.upfronthosting.co.za>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

I'm using sqlitebck which provides similar functionality but instead of using a file name to store the backup it uses connection instances.
I find it very useful. Here is my use case: to run tests of an application that requires a database filled, I do a 'copy' of an existing sqlite backup in a ':memory:' database.
But with the proposed API, it is not possible to use the resulted ':memory:' database because it will be delete when the connection is closed.
So I propose to add the option to pass a connection instead of a filename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Mon Oct 23 06:09:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 10:09:51 +0000
Subject: [issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()
In-Reply-To: <1506275205.91.0.662869765666.issue31572@psf.upfronthosting.co.za>
Message-ID: <1508753391.51.0.213398074469.issue31572@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4051

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31572>
_______________________________________

From report at bugs.python.org  Mon Oct 23 06:21:22 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 10:21:22 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1508754082.32.0.213398074469.issue27141@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I prefer issue27141_patch_rev1_opt1.patch. But now we use GitHub. Do you mind to create a pull request Bar?

----------
stage:  -> needs patch
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Mon Oct 23 06:43:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 10:43:03 +0000
Subject: [issue28143] ASDL compatibility with Python 3 system interpreter
In-Reply-To: <1473843180.28.0.653391200015.issue28143@psf.upfronthosting.co.za>
Message-ID: <1508755383.15.0.213398074469.issue28143@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a pull request on GitHub Malthe?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28143>
_______________________________________

From report at bugs.python.org  Mon Oct 23 06:58:51 2017
From: report at bugs.python.org (Malthe Borch)
Date: Mon, 23 Oct 2017 10:58:51 +0000
Subject: [issue28143] ASDL compatibility with Python 3 system interpreter
In-Reply-To: <1473843180.28.0.653391200015.issue28143@psf.upfronthosting.co.za>
Message-ID: <1508756331.41.0.213398074469.issue28143@psf.upfronthosting.co.za>


Change by Malthe Borch <mborch at gmail.com>:


----------
pull_requests: +4052
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28143>
_______________________________________

From report at bugs.python.org  Mon Oct 23 07:09:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 11:09:54 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508756994.09.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is it all with this issue?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Mon Oct 23 07:17:07 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 11:17:07 +0000
Subject: [issue28506] Multiprocessing Pool starmap - struct.error: 'i' format
 requires -2e10<=n<=2e10
In-Reply-To: <1477153852.62.0.286648862234.issue28506@psf.upfronthosting.co.za>
Message-ID: <1508757427.81.0.213398074469.issue28506@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Closed as a duplicate of issue17560.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28506>
_______________________________________

From report at bugs.python.org  Mon Oct 23 07:18:07 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 11:18:07 +0000
Subject: [issue28509] dict.update allocates too much
In-Reply-To: <1477163617.95.0.961480932723.issue28509@psf.upfronthosting.co.za>
Message-ID: <1508757487.76.0.213398074469.issue28509@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -839

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28509>
_______________________________________

From report at bugs.python.org  Mon Oct 23 07:25:30 2017
From: report at bugs.python.org (Sviatoslav Abakumov)
Date: Mon, 23 Oct 2017 11:25:30 +0000
Subject: [issue31845] Envvar PYTHONDONTWRITEBYTECODE is not respected
Message-ID: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>


New submission from Sviatoslav Abakumov <dust.harvesting at gmail.com>:

Setting PYTHONDONTWRITEBYTECODE doesn't seem to have an effect in Python 3.7.0a2:

    $ python -V
    Python 3.7.0a2
    $ env PYTHONDONTWRITEBYTECODE=1 python -c 'import sys; print(sys.dont_write_bytecode)'
    False

----------
components: Interpreter Core
messages: 304794
nosy: Perlence
priority: normal
severity: normal
status: open
title: Envvar PYTHONDONTWRITEBYTECODE is not respected
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:00:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 12:00:46 +0000
Subject: [issue31572] Avoid suppressing all exceptions in PyObject_HasAttr()
In-Reply-To: <1506275205.91.0.662869765666.issue31572@psf.upfronthosting.co.za>
Message-ID: <1508760046.16.0.213398074469.issue31572@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 77af0a3bcab666a356eea2927a8031a7578d60d2 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-31572: Get rid of using _PyObject_HasAttrId() in pickle. (GH-3729). (#4081)
https://github.com/python/cpython/commit/77af0a3bcab666a356eea2927a8031a7578d60d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31572>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:04:23 2017
From: report at bugs.python.org (Sviatoslav Abakumov)
Date: Mon, 23 Oct 2017 12:04:23 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508760263.11.0.213398074469.issue31845@psf.upfronthosting.co.za>


Sviatoslav Abakumov <dust.harvesting at gmail.com> added the comment:

Looks like PYTHONOPTIMIZE has no effect either:

    $ python -V
    Python 3.7.0a2
    $ env PYTHONOPTIMIZE=1 python -c 'import sys; print(sys.flags.optimize)'
    0

----------
title: Envvar PYTHONDONTWRITEBYTECODE is not respected -> PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:31:36 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 12:31:36 +0000
Subject: [issue30695] add a nomemory_allocator to the _testcapi module
In-Reply-To: <1497781271.4.0.00244472655339.issue30695@psf.upfronthosting.co.za>
Message-ID: <1508761896.18.0.213398074469.issue30695@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Test cases in issues #30697 and #30817, back ported to 3.6, need _testcapi.set_nomemory().

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30695>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:34:19 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Oct 2017 12:34:19 +0000
Subject: [issue30695] add a nomemory_allocator to the _testcapi module
In-Reply-To: <1497781271.4.0.00244472655339.issue30695@psf.upfronthosting.co.za>
Message-ID: <1508762059.08.0.213398074469.issue30695@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4053
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30695>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:43:56 2017
From: report at bugs.python.org (Sviatoslav Abakumov)
Date: Mon, 23 Oct 2017 12:43:56 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508762636.01.0.213398074469.issue31845@psf.upfronthosting.co.za>


Sviatoslav Abakumov <dust.harvesting at gmail.com> added the comment:

It seems 1abcf67[1] is the first bad commit.

[1]https://github.com/python/cpython/commit/1abcf6700b4da6207fe859de40c6c1bada6b4fec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:46:04 2017
From: report at bugs.python.org (Nathan Henrie)
Date: Mon, 23 Oct 2017 12:46:04 +0000
Subject: [issue31846] Error in 3.6.3 epub docs
Message-ID: <1508762764.69.0.213398074469.issue31846@psf.upfronthosting.co.za>


New submission from Nathan Henrie <n8henrie at gmail.com>:

I routinely download the epub version of the docs to my computer and mobile devices as an offline copy. The 3.6.3 version reports a big error on the first (and many other pages):

> This page contains the following errors:
error on line 5176 at column 11: Entity 'copy' not defined
Below is a rendering of the page up to the first error.

Numerous similar errors reporting `Entity 'copy' not defined` scattered throughout the epub.

Wonder if this was introduced by the change to `conf.py` that fixed the recent problem of the 404s with the HTML docs.

----------
messages: 304799
nosy: n8henrie
priority: normal
severity: normal
status: open
title: Error in 3.6.3 epub docs
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31846>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:52:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 12:52:13 +0000
Subject: [issue31847] Fix commented out tests in test_syntax
Message-ID: <1508763133.89.0.213398074469.issue31847@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Two doctest tests in test_syntax are commented out because SyntaxWarning was expected, but doctests couldn't be used for testing them.

But now SyntaxError is raised in these cases instead of SyntaxWarning.

The proposed PR restores and fixes tests.

----------
assignee: serhiy.storchaka
components: Tests
messages: 304800
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix commented out tests in test_syntax
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31847>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:54:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 12:54:35 +0000
Subject: [issue31847] Fix commented out tests in test_syntax
In-Reply-To: <1508763133.89.0.213398074469.issue31847@psf.upfronthosting.co.za>
Message-ID: <1508763275.95.0.213398074469.issue31847@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4054

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31847>
_______________________________________

From report at bugs.python.org  Mon Oct 23 08:58:50 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 12:58:50 +0000
Subject: [issue28028] Convert warnings to SyntaxWarning in parser
In-Reply-To: <1473362584.72.0.509126494717.issue28028@psf.upfronthosting.co.za>
Message-ID: <1508763530.14.0.213398074469.issue28028@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Closed because I don't see ways to do this.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28028>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:05:48 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 13:05:48 +0000
Subject: [issue30695] add a nomemory_allocator to the _testcapi module
In-Reply-To: <1497781271.4.0.00244472655339.issue30695@psf.upfronthosting.co.za>
Message-ID: <1508763948.41.0.213398074469.issue30695@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:


New changeset aaf6a3dbbdb9754f98d480b468adfcae0f66e3a2 by xdegaye (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-30695: Add set_nomemory(start, stop) to _testcapi (GH-2406) (#4083)
https://github.com/python/cpython/commit/aaf6a3dbbdb9754f98d480b468adfcae0f66e3a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30695>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:24:32 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 13:24:32 +0000
Subject: [issue30695] add a nomemory_allocator to the _testcapi module
In-Reply-To: <1497781271.4.0.00244472655339.issue30695@psf.upfronthosting.co.za>
Message-ID: <1508765072.19.0.213398074469.issue30695@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30695>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:25:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 13:25:24 +0000
Subject: [issue28564] shutil.rmtree is inefficient due to listdir() instead of
 scandir()
In-Reply-To: <1477857759.23.0.231777495226.issue28564@psf.upfronthosting.co.za>
Message-ID: <1508765124.96.0.213398074469.issue28564@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4055

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28564>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:26:26 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 13:26:26 +0000
Subject: [issue30817] Abort in PyErr_PrintEx() when no memory
In-Reply-To: <1498832371.19.0.0580869338001.issue30817@psf.upfronthosting.co.za>
Message-ID: <1508765186.63.0.213398074469.issue30817@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
stage:  -> patch review
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30817>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:26:46 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Oct 2017 13:26:46 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508765206.98.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

I need this too. I would like to set this

https://github.com/plures/ndtypes/commit/c260fdbae707da0dfefef499621a0a9f37a3e509#diff-2402fff6223084b74d97237c0d620b29R50

to something line PyMem_AlignedAlloc(), because the Python allocator is faster.


I think many people would welcome this in scientific computing: The Arrow memory format for example recommends 64 bit alignment.

----------
nosy: +skrah
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:33:01 2017
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Mon, 23 Oct 2017 13:33:01 +0000
Subject: [issue31848] "aifc" module does not always initialize
 "Aifc_read._ssnd_chunk"
Message-ID: <1508765581.06.0.213398074469.issue31848@psf.upfronthosting.co.za>


New submission from Stephen Paul Chappell <Noctis.Skytower at gmail.com>:

When Aifc_read runs initfp, it conditionally sets self._ssnd_chunk and is not guaranteed to do so. At the bottom of the method, a check is made to see if the attribute has a false value; and if so, an error is supposed to be raised. If a SSND chunk is never found, checking self._ssnd_chunk causes an attribute error to be raised similar to this:

AttributeError: 'Aifc_read' object has no attribute '_ssnd_chunk'

The error was found on the following distribution:

Python 3.6.2 (v3.6.2:5fd33b5, Jul  8 2017, 04:57:36) [MSC v.1900 64 bit (AMD64)] on win32

----------
components: Library (Lib), Tests
messages: 304804
nosy: Zero
priority: normal
severity: normal
status: open
title: "aifc" module does not always initialize "Aifc_read._ssnd_chunk"
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31848>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:35:54 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Oct 2017 13:35:54 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508765754.01.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

Do you need aligned allocation even on small objects?  The Python allocator doesn't handle allocations > 512 bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 09:49:01 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 13:49:01 +0000
Subject: [issue28660] TextWrapper break_long_words=True,
 break_on_hyphens=True on long words
In-Reply-To: <1478795701.76.0.659915154246.issue28660@psf.upfronthosting.co.za>
Message-ID: <1508766541.18.0.213398074469.issue28660@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is because the current algorithm of breaking on hyphens allows to break only between letters. This prevents breaking dates and times. Perhaps it should be made more lenient in the case of too long word.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28660>
_______________________________________

From report at bugs.python.org  Mon Oct 23 10:07:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 14:07:12 +0000
Subject: [issue27142] Default int value with xmlrpclib / xmlrpc.client
In-Reply-To: <1464387462.23.0.765030008479.issue27142@psf.upfronthosting.co.za>
Message-ID: <1508767632.73.0.213398074469.issue27142@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27142>
_______________________________________

From report at bugs.python.org  Mon Oct 23 10:11:28 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Oct 2017 14:11:28 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508767888.51.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

Yes, I think it is partly convenience. I want to set ...

   ndt_mallocfunc = PyMem_Malloc;
   ndt_alignedallocfunc = PyMem_AlignedAlloc;
   ndt_callocfunc = PyMem_Calloc;
   ndt_reallocfunc = PyMem_Realloc;
   ndt_freefunc = PyMem_Free;

... so I can always just call ndt_free(), because there's only one memory
allocator.


But the other part is that datashape allows to specify alignment regardless
of the size of the type.  Example:

>>> from ndtypes import *
>>> from xnd import *
>>> t = ndt("{a: int64, b: uint64, align=16}")
>>> xnd(t, {'a': 111, 'b': 222})
<xnd.xnd object at 0x7f82750c2a30>


The xnd object essentially wraps a typed data pointer. In the above case, the
'align' keyword has the same purpose as gcc's __attribute__((aligned(16))).


There are several other cases in datashape where alignment can specified
explicitly.


For the convenience case it would already help if PyMem_AlignedAlloc() did
*not* use the fast allocator, but just delegated to _aligned_malloc() (MSVC)
or aligned_alloc() (C11), ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 10:12:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 14:12:34 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508767954.33.0.213398074469.issue31752@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4ffd4653a7ec9c97775472276cf5e159e2366bb2 by Serhiy Storchaka in branch 'master':
bpo-31752: Fix possible crash in timedelta constructor called with custom integers. (#3947)
https://github.com/python/cpython/commit/4ffd4653a7ec9c97775472276cf5e159e2366bb2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Mon Oct 23 10:12:38 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Oct 2017 14:12:38 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508767958.55.0.213398074469.issue31752@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4056

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Mon Oct 23 10:14:11 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Oct 2017 14:14:11 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508768051.06.0.213398074469.issue18835@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 10:55:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 14:55:37 +0000
Subject: [issue26861] shutil.copyfile() doesn't close the opened files
In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za>
Message-ID: <1508770537.77.0.213398074469.issue26861@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26861>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:03:35 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 15:03:35 +0000
Subject: [issue30817] Abort in PyErr_PrintEx() when no memory
In-Reply-To: <1498832371.19.0.0580869338001.issue30817@psf.upfronthosting.co.za>
Message-ID: <1508771015.05.0.213398074469.issue30817@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Removing 2.7 as the problem cannot be reproduced here. PyEval_CallObjectWithKeywords() does not assert on PyErr_Occurred().

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30817>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:20:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 15:20:16 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508772016.08.0.213398074469.issue31752@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6e45d7b90accbbdfef353c41ab0a78a3e4742803 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31752: Fix possible crash in timedelta constructor called with custom integers. (GH-3947) (#4086)
https://github.com/python/cpython/commit/6e45d7b90accbbdfef353c41ab0a78a3e4742803


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:41:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 15:41:26 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508773286.44.0.213398074469.issue31835@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4057
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:44:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 15:44:40 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508773480.11.0.213398074469.issue31835@psf.upfronthosting.co.za>


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

> The fix is simple. Replace the faulty sub-expression by
> (co->co_flags & (~PyCF_MASK)) == (CO_OPTIMIZED | CO_NEWLOCALS | CO_NOFREE))

I proposed PR 4087 to implement this optimization.

I wouldn't call it a "fix", since the "co->co_flags == (CO_OPTIMIZED | CO_NEWLOCALS | CO_NOFREE)" check exists since Python 2.7 at least (whereas Python 2.7 also has CO_FUTURE_xxx flags).

> Just a minor performance issue.

I prefer to call it a performance opportunity :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:45:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 15:45:21 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508773521.25.0.213398074469.issue31835@psf.upfronthosting.co.za>


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

I reset Versions to Python 3.7. I don't consider this issue as a bug, but only as a new optimization. So it can only go into the future Python 3.7.

----------
versions:  -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:50:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 15:50:28 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508773828.57.0.213398074469.issue31752@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4058

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:53:30 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 15:53:30 +0000
Subject: [issue23224] LZMADecompressor object is only initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1508774010.0.0.213398074469.issue23224@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +Oren Milman
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23224>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:56:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 15:56:49 +0000
Subject: [issue28645] Drop __aiter__ compatibility layer from 3.7
In-Reply-To: <1478653887.8.0.479967053131.issue28645@psf.upfronthosting.co.za>
Message-ID: <1508774209.64.0.213398074469.issue28645@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a pull request Yury?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28645>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:58:28 2017
From: report at bugs.python.org (emtone)
Date: Mon, 23 Oct 2017 15:58:28 +0000
Subject: [issue31833] Compile fail on gentoo for MIPS CPU of loongson 2f
In-Reply-To: <1508560342.69.0.213398074469.issue31833@psf.upfronthosting.co.za>
Message-ID: <1508774308.79.0.213398074469.issue31833@psf.upfronthosting.co.za>


emtone <tong__hui at 163.com> added the comment:

I update the Python to 2.7.14 and It's Compile success.

Here is running the command with strace:
yeeloong /home/gentoo # python --version
Python 2.7.14
yeeloong /home/gentoo # strace -o ./python_strace.txt python -c "import
_multiprocessing"

----------
Added file: https://bugs.python.org/file47231/python_strace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31833>
_______________________________________

From report at bugs.python.org  Mon Oct 23 11:59:37 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Oct 2017 15:59:37 +0000
Subject: [issue31833] Compile fail on gentoo for MIPS CPU of loongson 2f
In-Reply-To: <1508560342.69.0.213398074469.issue31833@psf.upfronthosting.co.za>
Message-ID: <1508774377.53.0.213398074469.issue31833@psf.upfronthosting.co.za>


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

If it works with 2.7.14 then we can just close this issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31833>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:01:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 16:01:16 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508774476.73.0.213398074469.issue28936@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a pull request Ivan?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:01:16 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 16:01:16 +0000
Subject: [issue31849] Python/pyhash.c warning: comparison of integers of
 different signs
Message-ID: <1508774476.87.0.213398074469.issue31849@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When built with: Android clang version 3.8.275480  (based on LLVM 3.8.275480)

The following warning is emitted:

ccache /pathto/android/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target x86_64-none-linux-androideabi -gcc-toolchain /pathto/android/android-ndk/toolchains/x86_64-4.9/prebuilt/linux-x86_64 -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes --sysroot=/pathto/android/android-ndk/sysroot -D__ANDROID_API__=21 -isystem /pathto/android/android-ndk/sysroot/usr/include/x86_64-linux-android -Wno-unused-value -Wno-empty-body -Qunused-arguments -Wno-nullability-completeness -Wno-parentheses-equality   -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -IObjects -IInclude -IPython -I. -I/pathto/src/python/master/Include -I/pathto/tmp/android-makesetup/build/python3.7-extlibs-android-21-x86_64//data/local/tmp/python/include --sysroot=/pathto/android/android-ndk/sysroot -D__ANDROID_API__=21 -isystem /pathto/android/android-ndk/sysroot/usr/include/x86_64-linux-android   -DPy_BUILD_CORE -o Python/pyhash.o /pathto/src/python/master/Python/pyhash.c
/pathto/src/python/master/Python/pyhash.c:275:11: warning: comparison of integers of different signs: 'Py_uhash_t' (aka 'unsigned long') and 'int' [-Wsign-compare]
    if (x == -1) {
        ~ ^  ~~
1 warning generated.

----------
components: Interpreter Core
messages: 304816
nosy: christian.heimes, xdegaye
priority: normal
severity: normal
status: open
title: Python/pyhash.c warning: comparison of integers of different signs
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31849>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:03:20 2017
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 23 Oct 2017 16:03:20 +0000
Subject: [issue5430] imaplib: must not replace LF or CR by CRLF in literals
In-Reply-To: <1236325877.36.0.637700625895.issue5430@psf.upfronthosting.co.za>
Message-ID: <1508774600.91.0.213398074469.issue5430@psf.upfronthosting.co.za>


Change by Matej Cepl <mcepl at redhat.com>:


----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5430>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:03:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 16:03:39 +0000
Subject: [issue31849] Python/pyhash.c warning: comparison of integers of
 different signs
In-Reply-To: <1508774476.87.0.213398074469.issue31849@psf.upfronthosting.co.za>
Message-ID: <1508774619.32.0.213398074469.issue31849@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy (C)
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31849>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:08:43 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 Oct 2017 16:08:43 +0000
Subject: [issue30817] Abort in PyErr_PrintEx() when no memory
In-Reply-To: <1498832371.19.0.0580869338001.issue30817@psf.upfronthosting.co.za>
Message-ID: <1508774923.5.0.213398074469.issue30817@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:


New changeset 66caacf2f0d6213b049a3097556e28e30440b900 by xdegaye in branch 'master':
bpo-30817: Fix PyErr_PrintEx() when no memory (#2526)
https://github.com/python/cpython/commit/66caacf2f0d6213b049a3097556e28e30440b900


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30817>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:11:36 2017
From: report at bugs.python.org (emtone)
Date: Mon, 23 Oct 2017 16:11:36 +0000
Subject: [issue31833] Compile fail on gentoo for MIPS CPU of loongson 2f
In-Reply-To: <1508560342.69.0.213398074469.issue31833@psf.upfronthosting.co.za>
Message-ID: <1508775096.83.0.213398074469.issue31833@psf.upfronthosting.co.za>


emtone <tong__hui at 163.com> added the comment:

OK, Thank you pitrou!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31833>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:16:11 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Oct 2017 16:16:11 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508775371.93.0.213398074469.issue31845@psf.upfronthosting.co.za>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:17:55 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 23 Oct 2017 16:17:55 +0000
Subject: [issue28645] Drop __aiter__ compatibility layer from 3.7
In-Reply-To: <1478653887.8.0.479967053131.issue28645@psf.upfronthosting.co.za>
Message-ID: <1508775475.71.0.213398074469.issue28645@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Already resolved as part of https://bugs.python.org/issue31709. Closing this one.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Drop support for asynchronous __aiter__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28645>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:47:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 16:47:55 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508777275.09.0.213398074469.issue31845@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:50:49 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 23 Oct 2017 16:50:49 +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: <1508777449.78.0.213398074469.issue23699@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

PR has been rebased on top of master and also blurbified.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:57:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 16:57:06 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508777826.87.0.213398074469.issue31752@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5ef883b096895a84123760859f0f34ad37bf2277 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-31752: Fix possible crash in timedelta constructor called with custom integers. (GH-3947) (#4088)
https://github.com/python/cpython/commit/5ef883b096895a84123760859f0f34ad37bf2277


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Mon Oct 23 12:57:20 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 16:57:20 +0000
Subject: [issue31752] Assertion failure in timedelta() in case of bad
 __divmod__
In-Reply-To: <1507670968.8.0.213398074469.issue31752@psf.upfronthosting.co.za>
Message-ID: <1508777840.98.0.213398074469.issue31752@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31752>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:03:01 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Oct 2017 17:03:01 +0000
Subject: [issue30549] ProcessPoolExecutor hangs forever if the object raises
 on __getstate__
In-Reply-To: <1496394957.59.0.444319046255.issue30549@psf.upfronthosting.co.za>
Message-ID: <1508778181.4.0.213398074469.issue30549@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Deadlocks in `concurrent.futures.ProcessPoolExecutor`

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30549>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:04:40 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 Oct 2017 17:04:40 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1508778280.83.0.213398074469.issue31826@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The version in distutils is derived from sys.version and should be left as is too.  Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31826>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:06:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 17:06:34 +0000
Subject: [issue29202] Improve dict iteration
In-Reply-To: <1483869036.69.0.874318106576.issue29202@psf.upfronthosting.co.za>
Message-ID: <1508778394.66.0.213398074469.issue29202@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a pull request Raymond?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29202>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:08:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 17:08:02 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508778482.32.0.213398074469.issue18835@psf.upfronthosting.co.za>


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


----------
pull_requests: +4059
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:10:50 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Oct 2017 17:10:50 +0000
Subject: [issue30722] Tools/demo/redemo.py broken
In-Reply-To: <1498035463.93.0.0897725262949.issue30722@psf.upfronthosting.co.za>
Message-ID: <1508778650.37.0.213398074469.issue30722@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 62adc55aff0b78447568f73bd1abc610d2784bf8 by Berker Peksag (Christoph Sarnowski) in branch 'master':
bpo-30722: Make redemo work with Python 3.6+ (GH-2311)
https://github.com/python/cpython/commit/62adc55aff0b78447568f73bd1abc610d2784bf8


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30722>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:11:59 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Oct 2017 17:11:59 +0000
Subject: [issue30722] Tools/demo/redemo.py broken
In-Reply-To: <1498035463.93.0.0897725262949.issue30722@psf.upfronthosting.co.za>
Message-ID: <1508778719.07.0.213398074469.issue30722@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4060
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30722>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:16:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 17:16:05 +0000
Subject: [issue29084] C API of OrderedDict
In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za>
Message-ID: <1508778965.29.0.213398074469.issue29084@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29084>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:16:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 17:16:53 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508779013.57.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

I added _PyTraceMalloc_Track() and _PyTraceMalloc_Untrack() private functions to the C API in Python 3.6. These functions were made public in Python 3.7: renamed to PyTraceMalloc_Track() and PyTraceMalloc_Untrack(). I made this change to allow numpy to trace memory allocations, to debug memory leaks.

numpy cannot use Python memory allocators because numpy requires aligned memory blocks which are required to use CPU SIMD instructions.


Stefan Krah:
> I think many people would welcome this in scientific computing: The Arrow memory format for example recommends 64 bit alignment.

Ah, that's an interesting use case.

I created attached PR 4089 to implement PyMem_AlignedAlloc():

   void* PyMem_AlignedAlloc(size_t alignment, size_t size);
   void PyMem_AlignedFree(void *ptr);

Memory allocated by PyMem_AlignedAlloc() must be freed with PyMem_AlignedFree().

We cannot reuse PyMem_Free(). On Windows, PyMem_AlignedAlloc() is implemented with _aligned_malloc() which requires to release the memory with _aligned_free().


Raymond Hettinger:
>> Adding yet another API to allocate memory has a cost
> Please don't FUD this one to death.

Statistics (size) on my PR:

 Doc/c-api/memory.rst                              |  43 +-
 Doc/whatsnew/3.7.rst                              |   4 +
 Include/internal/mem.h                            |   6 +-
 Include/objimpl.h                                 |   2 +
 Include/pymem.h                                   |  16 +-
 .../2017-10-23-19-03-38.bpo-18835.8XEjtG.rst      |   9 +
 Modules/_testcapimodule.c                         |  83 ++-
 Modules/_tracemalloc.c                            | 131 +++-
 Objects/obmalloc.c                                | 616 +++++++++++++------
 9 files changed, 655 insertions(+), 255 deletions(-)

That's quite a big change "just to add PyMem_AlignedAlloc()" :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:19:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 17:19:58 +0000
Subject: [issue29368] Optimize unpickling list-like objects: use extend()
 instead of append()
In-Reply-To: <1485338150.33.0.560817507263.issue29368@psf.upfronthosting.co.za>
Message-ID: <1508779198.93.0.213398074469.issue29368@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -836

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29368>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:34:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 17:34:11 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1508780051.44.0.213398074469.issue31653@psf.upfronthosting.co.za>


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


----------
pull_requests: +4061

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:40:38 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Oct 2017 17:40:38 +0000
Subject: [issue30722] Tools/demo/redemo.py broken
In-Reply-To: <1498035463.93.0.0897725262949.issue30722@psf.upfronthosting.co.za>
Message-ID: <1508780438.5.0.213398074469.issue30722@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset a5f9d24c171c7e3a3715161fd16b747c7dcaf76f by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-30722: Make redemo work with Python 3.6+ (GH-2311)
https://github.com/python/cpython/commit/a5f9d24c171c7e3a3715161fd16b747c7dcaf76f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30722>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:42:56 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Oct 2017 17:42:56 +0000
Subject: [issue30722] Tools/demo/redemo.py broken
In-Reply-To: <1498035463.93.0.0897725262949.issue30722@psf.upfronthosting.co.za>
Message-ID: <1508780576.38.0.213398074469.issue30722@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you, Christoph. I wasn't aware of Tools/demo/redemo.py and I must say it was fun to play with while reviewing PR 2311.

----------
components: +Demos and Tools -Regular Expressions
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30722>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:45:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 17:45:15 +0000
Subject: [issue31850] test_nntplib failed with "nntplib.NNTPDataError: line
 too long"
Message-ID: <1508780715.86.0.213398074469.issue31850@psf.upfronthosting.co.za>


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

test_nntplib failed on many buildbots yesterday with the "line too long" error. It may be related to bpo-28971.

Example:

http://buildbot.python.org/all/#/builders/12/builds/52

(...)
test_with_statement (test.test_nntplib.NetworkedNNTP_SSLTests) ... ok
test_xhdr (test.test_nntplib.NetworkedNNTP_SSLTests) ... ok
test_xover (test.test_nntplib.NetworkedNNTP_SSLTests) ... ERROR
test_zlogin (test.test_nntplib.NetworkedNNTP_SSLTests) ... ok
test_zzquit (test.test_nntplib.NetworkedNNTP_SSLTests) ... ok
test_module_all_attribute (test.test_nntplib.PublicAPITests) ... ok
test test_nntplib failed
test_we_are_in_reader_mode_after_connect (test.test_nntplib.SendReaderNNTPv2Tests) ... ok

======================================================================
ERROR: test_xover (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\test_nntplib.py", line 241, in wrapped
    meth(self)
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\test_nntplib.py", line 125, in test_xover
    resp, lines = self.server.xover(last - 5, last)
  File "D:\buildarea\3.x.ware-win81-release\build\lib\nntplib.py", line 804, in xover
    file)
  File "D:\buildarea\3.x.ware-win81-release\build\lib\nntplib.py", line 525, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "D:\buildarea\3.x.ware-win81-release\build\lib\nntplib.py", line 494, in _getlongresp
    line = self._getline()
  File "D:\buildarea\3.x.ware-win81-release\build\lib\nntplib.py", line 434, in _getline
    raise NNTPDataError('line too long')
nntplib.NNTPDataError: line too long

----------
components: Tests
keywords: buildbot
messages: 304829
nosy: haypo
priority: normal
severity: normal
status: open
title: test_nntplib failed with "nntplib.NNTPDataError: line too long"
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31850>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:48:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 17:48:04 +0000
Subject: [issue29438] use after free in key sharing dict
In-Reply-To: <1486169576.7.0.502230969893.issue29438@psf.upfronthosting.co.za>
Message-ID: <1508780884.38.0.213398074469.issue29438@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -960

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29438>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:53:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 17:53:07 +0000
Subject: [issue31850] test_nntplib failed with "nntplib.NNTPDataError: line
 too long"
In-Reply-To: <1508780715.86.0.213398074469.issue31850@psf.upfronthosting.co.za>
Message-ID: <1508781187.13.0.213398074469.issue31850@psf.upfronthosting.co.za>


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

It also failed on Travis CI:

https://mail.python.org/pipermail/python-committers/2017-October/004910.html

Other buildbot failures:

http://buildbot.python.org/all/#builders/80/builds/17
http://buildbot.python.org/all/#/builders/3/builds/48
http://buildbot.python.org/all/#/builders/47/builds/51
http://buildbot.python.org/all/#/builders/99/builds/50
http://buildbot.python.org/all/#/builders/103/builds/50
http://buildbot.python.org/all/#/builders/88/builds/51
http://buildbot.python.org/all/#builders/85/builds/51
http://buildbot.python.org/all/#/builders/53/builds/52
http://buildbot.python.org/all/#/builders/12/builds/49
http://buildbot.python.org/all/#/builders/106/builds/51
http://buildbot.python.org/all/#/builders/13/builds/51
http://buildbot.python.org/all/#/builders/27/builds/50
http://buildbot.python.org/all/#/builders/16/builds/51
http://buildbot.python.org/all/#/builders/87/builds/50
http://buildbot.python.org/all/#/builders/90/builds/28
http://buildbot.python.org/all/#/builders/30/builds/47
http://buildbot.python.org/all/#/builders/32/builds/47

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31850>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:54:49 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 17:54:49 +0000
Subject: [issue31851] test_subprocess hangs randomly on x86 Windows7 3.x
Message-ID: <1508781289.15.0.213398074469.issue31851@psf.upfronthosting.co.za>


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

test_subprocess hanged on the build 46 of x86 Windows7 3.x:

http://buildbot.python.org/all/#/builders/58/builds/46

(...)
1:29:55 [405/407] test_cmath passed -- running: test_subprocess (1249 sec)
1:29:58 [406/407] test_pstats passed -- running: test_subprocess (1252 sec)

The buildbot is slow which might have caused a timing issue.

----------
components: Tests
keywords: buildbot
messages: 304831
nosy: haypo
priority: normal
severity: normal
status: open
title: test_subprocess hangs randomly on x86 Windows7 3.x
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31851>
_______________________________________

From report at bugs.python.org  Mon Oct 23 13:56:55 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 23 Oct 2017 17:56:55 +0000
Subject: [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1508781415.86.0.213398074469.issue25041@psf.upfronthosting.co.za>


Change by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests: +4062
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25041>
_______________________________________

From report at bugs.python.org  Mon Oct 23 14:07:59 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 Oct 2017 18:07:59 +0000
Subject: [issue31822] Document that urllib.parse.{Defrag, Split,
 Parse}Result are namedtuples
In-Reply-To: <1508439273.05.0.213398074469.issue31822@psf.upfronthosting.co.za>
Message-ID: <1508782079.14.0.213398074469.issue31822@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Mon Oct 23 15:05:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 19:05:32 +0000
Subject: [issue31822] Document that urllib.parse.{Defrag, Split,
 Parse}Result are namedtuples
In-Reply-To: <1508439273.05.0.213398074469.issue31822@psf.upfronthosting.co.za>
Message-ID: <1508785532.42.0.213398074469.issue31822@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

collections.namedtuples is not a class.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Mon Oct 23 15:08:43 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 Oct 2017 19:08:43 +0000
Subject: [issue31822] Document that urllib.parse.{Defrag, Split,
 Parse}Result are namedtuples
In-Reply-To: <1508439273.05.0.213398074469.issue31822@psf.upfronthosting.co.za>
Message-ID: <1508785723.09.0.213398074469.issue31822@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I suggest using :term:`named tuple` for the link (+ an example of using _replace as Mike said)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Mon Oct 23 15:11:27 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Oct 2017 19:11:27 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1508779013.57.0.213398074469.issue18835@psf.upfronthosting.co.za>
Message-ID: <20171023191116.GA14537@bytereef.org>


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

On Mon, Oct 23, 2017 at 05:16:53PM +0000, STINNER Victor wrote:
> Memory allocated by PyMem_AlignedAlloc() must be freed with PyMem_AlignedFree().
> 
> We cannot reuse PyMem_Free(). On Windows, PyMem_AlignedAlloc() is implemented with _aligned_malloc() which requires to release the memory with _aligned_free().

Ah, too bad. Of course Windows does something different again. This weakens
my use case somewhat, but I guess it would still be nice to have the functions
(if you think it's maintainable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 15:22:17 2017
From: report at bugs.python.org (Alexandre Hamelin)
Date: Mon, 23 Oct 2017 19:22:17 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
Message-ID: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>


New submission from Alexandre Hamelin <quad.on at gmail.com>:

Hi.

Python 3.6.2 crashes when interpreting lines with the text "async \" (future keyword 'async' and ending with a backslash).

Tested in a docker environment (debian jessie). (see github.com/0xquad/docker-python36 if needed)

Examples:

$ docker run -ti --rm python36
root at 4c09392f83c8:/# python3.6
Python 3.6.2 (default, Aug  4 2017, 14:35:04)
[GCC 6.4.0 20170724] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async \
...
  File "<stdin>", line 1
    \ufffd\ufffdF\ufffd\ufffd
         ^
SyntaxError: invalid syntax
>>> async \
Segmentation fault
root at 4c09392f83c8:/#



Also,

----- file: test.py
#/usr/bin/python3.6
async \
<repeated 30000 times>
-----

$ ./test.py
Segmentation fault
$


Haven't taken the time to produce a backtrace or investigate with latest the dev versions or any further.

Let me know if I can assist in any way.

----------
components: Interpreter Core
messages: 304835
nosy: Alexandre Hamelin
priority: normal
severity: normal
status: open
title: Crashes with lines of the form "async \"
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Mon Oct 23 15:49:11 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 23 Oct 2017 19:49:11 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508788151.77.0.213398074469.issue31800@psf.upfronthosting.co.za>


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

Note that #5288 relaxed the whole number of minutes restriction on UTC offsets.  Since the goal is to be able to parse the output of .isoformat(), I think %z should accept sub-minute offsets.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Mon Oct 23 15:53:15 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 23 Oct 2017 19:53:15 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508788395.44.0.213398074469.issue18835@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

There's also aligned calloc, which no native APIs support but is still quite useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 16:26:17 2017
From: report at bugs.python.org (Erik Aronesty)
Date: Mon, 23 Oct 2017 20:26:17 +0000
Subject: [issue31853] Use super().method instead of socket.method in SSLSocket
Message-ID: <1508790377.43.0.213398074469.issue31853@psf.upfronthosting.co.za>


New submission from Erik Aronesty <erik at q32.com>:

I asked on #python-dev and was told that it's most likely due to legacy reasons that the class has things like `socket.__init__` instead of `super().__init__`

----------
assignee: christian.heimes
components: SSL
messages: 304838
nosy: christian.heimes, earonesty
priority: normal
pull_requests: 4063
severity: normal
status: open
title: Use super().method instead of socket.method in SSLSocket
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Mon Oct 23 16:26:44 2017
From: report at bugs.python.org (Justus Schwabedal)
Date: Mon, 23 Oct 2017 20:26:44 +0000
Subject: [issue31854] Add mmap.ACCESS_DEFAULT to namespace
Message-ID: <1508790404.89.0.213398074469.issue31854@psf.upfronthosting.co.za>


New submission from Justus Schwabedal <jschwabedal at gmail.com>:

I propose to add mmap.ACCESS_DEFAULT into the namespace.  Accessing the default value might be necessary, if one needs to overwrite an `ACCESS` keyword argument.

----------
components: Extension Modules
messages: 304839
nosy: Justus Schwabedal
priority: normal
severity: normal
status: open
title: Add mmap.ACCESS_DEFAULT to namespace
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31854>
_______________________________________

From report at bugs.python.org  Mon Oct 23 16:28:04 2017
From: report at bugs.python.org (Mads Jensen)
Date: Mon, 23 Oct 2017 20:28:04 +0000
Subject: [issue31853] Use super().method instead of socket.method in SSLSocket
In-Reply-To: <1508790377.43.0.213398074469.issue31853@psf.upfronthosting.co.za>
Message-ID: <1508790484.42.0.213398074469.issue31853@psf.upfronthosting.co.za>


Change by Mads Jensen <mje at inducks.org>:


----------
nosy: +madsjensen -earonesty

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31853>
_______________________________________

From report at bugs.python.org  Mon Oct 23 16:34:18 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Oct 2017 20:34:18 +0000
Subject: [issue31854] Add mmap.ACCESS_DEFAULT to namespace
In-Reply-To: <1508790404.89.0.213398074469.issue31854@psf.upfronthosting.co.za>
Message-ID: <1508790858.25.0.213398074469.issue31854@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4064
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31854>
_______________________________________

From report at bugs.python.org  Mon Oct 23 16:57:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Oct 2017 20:57:57 +0000
Subject: [issue31653] Don't release the GIL if we can acquire a
 multiprocessing semaphore immediately
In-Reply-To: <1506822182.01.0.213398074469.issue31653@psf.upfronthosting.co.za>
Message-ID: <1508792277.89.0.213398074469.issue31653@psf.upfronthosting.co.za>


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


New changeset 828ca59208af0b1b52a328676c5cc0c5e2e999b0 by Victor Stinner in branch 'master':
bpo-31653: Remove deadcode in semlock_acquire() (#4091)
https://github.com/python/cpython/commit/828ca59208af0b1b52a328676c5cc0c5e2e999b0


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31653>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:03:10 2017
From: report at bugs.python.org (Ron Rothman)
Date: Mon, 23 Oct 2017 21:03:10 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
Message-ID: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>


New submission from Ron Rothman <ron.rothman at gmail.com>:

mock.mock_open works as expected when reading the entire file (read()) or when reading a single line (readline()), but it seems to not support reading a number of bytes (read(n)).

These work as expected:

    from mock import mock_open, patch

    # works: consume entire "file"
    with patch('__main__.open', mock_open(read_data='bibble')) as m:
        with open('foo') as h:
            result = h.read()

    assert result == 'bibble'  # ok

    # works: consume one line
    with patch('__main__.open', mock_open(read_data='bibble\nbobble')) as m:
        with open('foo') as h:
            result = h.readline()

    assert result == 'bibble\n'  # ok

But trying to read only a few bytes fails--mock_open returns the entire read_data instead:

    # consume first 3 bytes of the "file"
    with patch('__main__.open', mock_open(read_data='bibble')) as m:
        with open('foo') as h:
            result = h.read(3)

    assert result == 'bib', 'result of read: {}'.format(result)  # fails

Output:

    Traceback (most recent call last):
      File "/tmp/t.py", line 25, in <module>
        assert result == 'bib', 'result of read: {}'.format(result)
    AssertionError: result of read: bibble

The unfortunate effect of this is that mock_open cannot be used with pickle.load.

    with open('/path/to/file.pkl', 'rb') as f:
        x = pickle.load(f)  # this requires f.read(1) to work

----------
components: Library (Lib)
messages: 304841
nosy: ron.rothman
priority: normal
severity: normal
status: open
title: mock_open is not compatible with read(n) (and pickle.load)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:08:25 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Oct 2017 21:08:25 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1508792905.94.0.213398074469.issue27141@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4065
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:11:18 2017
From: report at bugs.python.org (Bar Harel)
Date: Mon, 23 Oct 2017 21:11:18 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1508793078.68.0.213398074469.issue27141@psf.upfronthosting.co.za>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Done :-)
Seems like I forgot to edit the news though, I'll try to edit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:16:08 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Oct 2017 21:16:08 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508793368.61.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

By the way:

> The Arrow memory format for example recommends 64 bit alignment.

I presume you mean 64 bytes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:21:44 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 21:21:44 +0000
Subject: [issue28253] calendar.prcal(9999) output has a problem
In-Reply-To: <68047ef2.6fd9.15755a09cdb.Coremail.xibeilijp@163.com>
Message-ID: <1508793704.06.0.213398074469.issue28253@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -982

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28253>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:23:19 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Oct 2017 21:23:19 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1508793368.61.0.213398074469.issue18835@psf.upfronthosting.co.za>
Message-ID: <20171023212309.GA3238@bytereef.org>


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

On Mon, Oct 23, 2017 at 09:16:08PM +0000, Antoine Pitrou wrote:
> > The Arrow memory format for example recommends 64 bit alignment.
> 
> I presume you mean 64 bytes?

Yes, I was typing too fast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:27:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 21:27:17 +0000
Subject: [issue31847] Fix commented out tests in test_syntax
In-Reply-To: <1508763133.89.0.213398074469.issue31847@psf.upfronthosting.co.za>
Message-ID: <1508794037.04.0.213398074469.issue31847@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3b66ebe7727dba68c2c6ccf0cd85a4c31255b9b4 by Serhiy Storchaka in branch 'master':
bpo-31847: Fix commented out tests in test_syntax. (#4084)
https://github.com/python/cpython/commit/3b66ebe7727dba68c2c6ccf0cd85a4c31255b9b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31847>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:27:41 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Oct 2017 21:27:41 +0000
Subject: [issue31847] Fix commented out tests in test_syntax
In-Reply-To: <1508763133.89.0.213398074469.issue31847@psf.upfronthosting.co.za>
Message-ID: <1508794061.72.0.213398074469.issue31847@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31847>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:38:04 2017
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Mon, 23 Oct 2017 21:38:04 +0000
Subject: [issue31828] Support Py_tss_NEEDS_INIT outside of static
 initialisation
In-Reply-To: <1508515676.46.0.213398074469.issue31828@psf.upfronthosting.co.za>
Message-ID: <1508794684.01.0.213398074469.issue31828@psf.upfronthosting.co.za>


Change by Masayuki Yamamoto <ma3yuki.8mamo10 at gmail.com>:


----------
keywords: +patch
pull_requests: +4067
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31828>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:39:26 2017
From: report at bugs.python.org (Ron Rothman)
Date: Mon, 23 Oct 2017 21:39:26 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
In-Reply-To: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>
Message-ID: <1508794766.73.0.213398074469.issue31855@psf.upfronthosting.co.za>


Ron Rothman <ron.rothman at gmail.com> added the comment:

Confirmed that the behavior exists in Python 3.6 as well.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:47:50 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 23 Oct 2017 21:47:50 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508795270.39.0.213398074469.issue28936@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
pull_requests: +4068
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Mon Oct 23 17:52:33 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 23 Oct 2017 21:52:33 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508795553.2.0.213398074469.issue28936@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

OK, I made a PR with the fix and a test that checks the line number for syntax error (so that the original purpose test_global_err_then_warn is preserved).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Mon Oct 23 18:08:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Oct 2017 22:08:05 +0000
Subject: [issue31847] Fix commented out tests in test_syntax
In-Reply-To: <1508763133.89.0.213398074469.issue31847@psf.upfronthosting.co.za>
Message-ID: <1508796485.34.0.213398074469.issue31847@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d7604f5d0621c23d037455acd682d0d489455d54 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31847: Fix commented out tests in test_syntax. (GH-4084) (#4095)
https://github.com/python/cpython/commit/d7604f5d0621c23d037455acd682d0d489455d54


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31847>
_______________________________________

From report at bugs.python.org  Mon Oct 23 19:25:05 2017
From: report at bugs.python.org (Bob Kline)
Date: Mon, 23 Oct 2017 23:25:05 +0000
Subject: [issue31856] Unexpected behavior of re module when VERBOSE flag is set
Message-ID: <1508801105.35.0.213398074469.issue31856@psf.upfronthosting.co.za>


New submission from Bob Kline <bkline at rksystems.com>:

According to the documentation of the re module, "When this flag [re.VERBOSE] has been specified, whitespace within the RE string is ignored, except when the whitespace is in a character class or preceded by an unescaped backslash; this lets you organize and indent the RE more clearly. This flag also lets you put comments within a RE that will be ignored by the engine; comments are marked by a '#' that?s neither in a character class [n]or preceded by an unescaped backslash." (I'm quoting from the 3.6.3 documentation, but I've tested with several versions of Python, as indicated in the issue's `Versions` field, all with the same results.)

Given this description, I would have expected the output for each of the pairs of calls to findall() in the attached repro code to be the same, but that is not what's happening. In the case of the first pair of calls, for example, the non-verbose version finds two more matches than the verbose version, even though the regular expression is identical for the two calls, ignoring whitespace and comments in the expression string. Similar problems appear with the other two pairs of calls.

Here's the output from the attached code:

['&', '(', '/Term/SemanticType/@cdr:ref', '==']
['/Term/SemanticType/@cdr:ref', '==']
[' XXX ']
[]
[' XXX ']
[]

It would seem that at least one of the following is true:

 1. the module is not behaving as it should
 2. the documentation is wrong
 3. I have not understood the documentation correctly

I'm happy for it to be #3, as long as someone can explain what I have not understood.

----------
components: Library (Lib), Regular Expressions
files: regex-repro.py
messages: 304849
nosy: bkline, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Unexpected behavior of re module when VERBOSE flag is set
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47232/regex-repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31856>
_______________________________________

From report at bugs.python.org  Mon Oct 23 19:26:08 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 23 Oct 2017 23:26:08 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508801168.74.0.213398074469.issue28936@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Am I needed here?

----------
nosy:  -Jeremy.Hylton

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Mon Oct 23 19:37:04 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 23 Oct 2017 23:37:04 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1508801824.67.0.213398074469.issue2651@psf.upfronthosting.co.za>


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

A new Stackoverflow question gives a better illustration of how special-casing KeyError can be a nuisance.
https://stackoverflow.com/questions/46892261/new-line-on-error-message-in-idle-python-3-3/46899120#46899120
>From a current repository build instead of 3.3:

>>> s = 'line\nbreak'
>>> raise Exception(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Exception: line
break
>>> raise KeyError(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'line\nbreak'
>

The OP wanted to get the line break to break without fudging the code to catch Exception rather than KeyError.  I proposed catching KeyError and then 'print(err.args[0]' instead of 'print(err)'.

Why this makes a difference, and why KeyError is unique in needing this, is obvious after I found this issue and read the code comment quoted by Amaury.  But it sure wasn't before.

The rational for applying repr only applies when there is exactly one arg of value ''.  So I think the fix should be to only apply it when args *is* ('',).  There is no reason to quote a non-blank message -- and suppress any formatting a user supplies.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2651>
_______________________________________

From report at bugs.python.org  Mon Oct 23 19:55:55 2017
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 23 Oct 2017 23:55:55 +0000
Subject: [issue31856] Unexpected behavior of re module when VERBOSE flag is set
In-Reply-To: <1508801105.35.0.213398074469.issue31856@psf.upfronthosting.co.za>
Message-ID: <1508802955.12.0.213398074469.issue31856@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Your verbose examples put the pattern into raw triple-quoted strings, which is OK, but their first character is a backslash, which makes the next character (a newline) an escaped literal whitespace character. Escaped whitespace is significant in a verbose pattern.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31856>
_______________________________________

From report at bugs.python.org  Mon Oct 23 20:53:00 2017
From: report at bugs.python.org (Bob Kline)
Date: Tue, 24 Oct 2017 00:53:00 +0000
Subject: [issue31856] Unexpected behavior of re module when VERBOSE flag is set
In-Reply-To: <1508801105.35.0.213398074469.issue31856@psf.upfronthosting.co.za>
Message-ID: <1508806380.32.0.213398074469.issue31856@psf.upfronthosting.co.za>


Bob Kline <bkline at rksystems.com> added the comment:

I had been under the impression that "escaped" in this context meant that an escape character (the backslash) was part of the string value for the regular expression (there's a little bit of overloading going on with that word). Thanks for setting me straight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31856>
_______________________________________

From report at bugs.python.org  Mon Oct 23 21:09:22 2017
From: report at bugs.python.org (pdox)
Date: Tue, 24 Oct 2017 01:09:22 +0000
Subject: [issue31857] Make the behavior of USE_STACKCHECK deterministic
Message-ID: <1508807362.1.0.213398074469.issue31857@psf.upfronthosting.co.za>


New submission from pdox <pdox at alum.mit.edu>:

USE_STACKCHECK is a Windows-only feature which provides additional safety against C stack overflow by periodically calling PyOS_CheckStack to determine whether the current thread is too close to the end of the stack.

The way USE_STACKCHECK ensures that PyOS_CheckStack is called frequently is surprising. It does this by artificially decrementing _Py_CheckRecursionLimit with every call to Py_EnterRecursiveCall:

    #ifdef USE_STACKCHECK
    /* With USE_STACKCHECK, we artificially decrement the recursion limit in order
       to trigger regular stack checks in _Py_CheckRecursiveCall(), except if
       the "overflowed" flag is set, in which case we need the true value
       of _Py_CheckRecursionLimit for _Py_MakeEndRecCheck() to function properly.
    */
    #  define _Py_MakeRecCheck(x)  \
        (++(x) > (_Py_CheckRecursionLimit += PyThreadState_GET()->overflowed - 1))
    #else
    #  define _Py_MakeRecCheck(x)  (++(x) > _Py_CheckRecursionLimit)
    #endif

_Py_CheckRecursionLimit defaults to 1000, and is constant when USE_STACKCHECK is off. (except when changed by Py_SetRecursionLimit)

With a single thread, each call to Py_EnterRecursiveCall causes _Py_CheckRecursionLimit to decrement by 1 until it equals the current recursion depth, at which point _Py_CheckRecursiveCall is triggered, resetting _Py_CheckRecursionLimit back to the default. This could be anywhere from 500 to 1000 calls depending on the recursion depth. With multiple threads, the behavior may be more chaotic, as each thread will be decrementing _Py_CheckRecursionLimit independently.

I propose that instead, the call to PyOS_CheckStack is triggered in a predictable fashion, using a separate counter for each thread, so that it occurs every N'th call to Py_EnterRecursiveCall. (N = 64 seems reasonable, as PyOS_CheckStack guarantees 2048 * sizeof(void*) bytes remaining on the C stack).

----------
components: Windows
messages: 304854
nosy: paul.moore, pdox, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Make the behavior of USE_STACKCHECK deterministic
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31857>
_______________________________________

From report at bugs.python.org  Mon Oct 23 21:31:05 2017
From: report at bugs.python.org (pdox)
Date: Tue, 24 Oct 2017 01:31:05 +0000
Subject: [issue31857] Make the behavior of USE_STACKCHECK deterministic
In-Reply-To: <1508807362.1.0.213398074469.issue31857@psf.upfronthosting.co.za>
Message-ID: <1508808665.94.0.213398074469.issue31857@psf.upfronthosting.co.za>


Change by pdox <pdox at alum.mit.edu>:


----------
keywords: +patch
pull_requests: +4069
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31857>
_______________________________________

From report at bugs.python.org  Mon Oct 23 23:20:17 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Oct 2017 03:20:17 +0000
Subject: [issue29202] Improve dict iteration
In-Reply-To: <1483869036.69.0.874318106576.issue29202@psf.upfronthosting.co.za>
Message-ID: <1508815217.64.0.213398074469.issue29202@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This doesn't meet our criteria for backports.

----------
assignee: rhettinger -> serhiy.storchaka
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29202>
_______________________________________

From report at bugs.python.org  Mon Oct 23 23:36:50 2017
From: report at bugs.python.org (Bob Kline)
Date: Tue, 24 Oct 2017 03:36:50 +0000
Subject: [issue31856] Unexpected behavior of re module when VERBOSE flag is set
In-Reply-To: <1508801105.35.0.213398074469.issue31856@psf.upfronthosting.co.za>
Message-ID: <1508816210.02.0.213398074469.issue31856@psf.upfronthosting.co.za>


Bob Kline <bkline at rksystems.com> added the comment:

The light finally comes on. I actually *was* putting a backslash into the string value, with the raw flag (which is, of course, what you were trying to tell me). Thanks for your patience. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31856>
_______________________________________

From report at bugs.python.org  Tue Oct 24 00:28:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Oct 2017 04:28:11 +0000
Subject: [issue31841] Several methods of collections.UserString do not return
 instances of UserString or its subclasses
In-Reply-To: <1508701595.06.0.213398074469.issue31841@psf.upfronthosting.co.za>
Message-ID: <1508819291.62.0.213398074469.issue31841@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I would support changing format() and format_map().

The join() method has been around for a long time, so changing it might do more harm than good.

----------
assignee:  -> lisroach
nosy: +lisroach, rhettinger
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31841>
_______________________________________

From report at bugs.python.org  Tue Oct 24 00:30:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Oct 2017 04:30:11 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1508819411.41.0.213398074469.issue27141@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Either of the patches looks fine.  I lean a bit towards the opt1 patch.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Tue Oct 24 00:32:25 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Oct 2017 04:32:25 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
In-Reply-To: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>
Message-ID: <1508819545.65.0.213398074469.issue31855@psf.upfronthosting.co.za>


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


----------
assignee:  -> michael.foord
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Tue Oct 24 01:34:29 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 05:34:29 +0000
Subject: [issue31847] Fix commented out tests in test_syntax
In-Reply-To: <1508763133.89.0.213398074469.issue31847@psf.upfronthosting.co.za>
Message-ID: <1508823269.29.0.213398074469.issue31847@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31847>
_______________________________________

From report at bugs.python.org  Tue Oct 24 01:57:54 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Oct 2017 05:57:54 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508824674.45.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

Having the ability to allocated aligned memory could help avoid some undefined behavior. See #27987 (though, we only need 16-byte alignment there)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 24 01:58:28 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 Oct 2017 05:58:28 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
Message-ID: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

This issue is about cleaning up IDLE's use of sys.ps1 for its prompt (sys.ps2 is not used).  A. This will make for cleaner code and fix some bugs.  B. This will be better for testing.  (Some possible changes to pyshell might make sys.ps1 irrelevant, but that is for the future.)

Part1. editor.EditorWindow.__init__ sets sys.ps1 to '>>> ' if not set.
        try:
            sys.ps1
        except AttributeError:
            sys.ps1 = '>>> '
IDLE initially respects a user setting of sys.ps1 in a startup file.

pyshell.PyShell.open_debugger hasand .close_debugger has these lines
        sys.ps1 = "[DEBUG ON]\n>>> "
            sys.ps1 = ">>> "
These overwrite any user setting of sys.ps1.  As long as IDLE pays attention to the initial value of sys.ps1, I consider this a bug.

pyshell.PyShell.show_prompt starts with
        try:
            s = str(sys.ps1)
        except:
            s = ""
        self.console.write(s)

I suspect that this is a holdover from when IDLE executed user code in its own process, as it still does with the deprecated '-n' option.  However, if a -n user deletes sys.ps1, the replacement should be '>>> ', not '' (bug 2).

In the current default subprocess mode, users cannot change the IDLE process sys module (see #13657), so rereading sys.ps1 for every editor window and prompt is nonsensical.

Patch 1: replace the EditorWindow.__init__ code with module level code
sys_ps1 = sys.ps1 if hasattr(sys, 'ps1') else '>>> '
prompt = sys_ps1

Fix pyshell to import editor rather than two of its objects.  In its debugger methods, set editor.prompt, using editor.sys_ps1, thus preserving any user setting.  In print_prompt, print the current editor.prompt.  (This will disable users resetting ps1 in deprecated -n mode, but I consider that okay as it matches the normal mode.)

Part 2. The reason the prompt is set in EditorWindow, instead of where is it obviously needed, the PyShell subclass of the OutputWindow subclass of EditorWindow, is that it is currently used in EditorWindow.smart_backspace_event and .newline_and_indent_event, while   pyshell imports editor (and must), and not the other way around.

Treating the prompt text as special in an editor lead to a bug in smart_backspace that was fixed in #13039 by guarding it use with self.context_use_ps1.  There is still a nearly inconsequential bug in the newline method where the prompt use is not guarded.  (Hitting newline with the cursor before the 't' in '>>> test' leaves the preceding space instead of deleting it.)

Patch 2: Only the last line of the prompt is relevant in either method.  I believe that replacing self.context_use_ps1 = False in an editor, = True in Shell with self.last_prompt_line = '' in an editor, = whatever it is in Shell, will allow moving sys_ps1 and prompt to pyshell.  This would simplify patch 1.

----------
assignee: terry.reedy
components: IDLE
messages: 304860
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: cleanup use of sys.ps1 and never set it.
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Tue Oct 24 02:06:00 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 24 Oct 2017 06:06:00 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508825160.12.0.213398074469.issue28936@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Am I needed here?

As I understand, Serhiy is going to review the PR, so I think no.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Tue Oct 24 02:23:50 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 Oct 2017 06:23:50 +0000
Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2.
In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>
Message-ID: <1508826230.49.0.213398074469.issue13657@psf.upfronthosting.co.za>


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

#31858 fixes pyshell and editor so that a user setting of sys.ps1 in a startup file continues to be used after turning debugger on, instead of erased. I consider this to be an IDLE documentation issue, to add something in the introduction.  Discussing IDLE differences in the tutorial might need more discussion than just here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Tue Oct 24 02:38:57 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Oct 2017 06:38:57 +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: <1508827137.98.0.213398074469.issue23699@psf.upfronthosting.co.za>


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

IMO, "op" should be the first argument to the macro, since that reflects the tp_richcmp API.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Tue Oct 24 02:45:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 06:45:59 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508827559.05.0.213398074469.issue28936@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry for disturbing you Guido. I had added you as the committer of issue27999. Do you have thoughts about this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Tue Oct 24 02:54:21 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Oct 2017 06:54:21 +0000
Subject: [issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower
 than reference
In-Reply-To: <1508572631.92.0.213398074469.issue31834@psf.upfronthosting.co.za>
Message-ID: <1508828061.68.0.213398074469.issue31834@psf.upfronthosting.co.za>


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


New changeset 1aa00ff383c43335e4a5044274617dbf59bc839e by Benjamin Peterson (Micha? G?rny) in branch 'master':
fixes bpo-31834: Use optimized code for BLAKE2 only with SSSE3+ (#4066)
https://github.com/python/cpython/commit/1aa00ff383c43335e4a5044274617dbf59bc839e


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31834>
_______________________________________

From report at bugs.python.org  Tue Oct 24 03:08:38 2017
From: report at bugs.python.org (Bar Harel)
Date: Tue, 24 Oct 2017 07:08:38 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1508828918.12.0.213398074469.issue27141@psf.upfronthosting.co.za>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Alrighty then, opt1 passed all tests and waiting on GitHub for inclusion :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Tue Oct 24 03:25:04 2017
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 24 Oct 2017 07:25:04 +0000
Subject: [issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower
 than reference
In-Reply-To: <1508572631.92.0.213398074469.issue31834@psf.upfronthosting.co.za>
Message-ID: <1508829904.18.0.213398074469.issue31834@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm pretty sure that your PR has disabled all SSE optimizations. AFAIK gcc does not enable SSE3 and SSE4 on X86_64 by default.

$ gcc -dM -E - < /dev/null | grep SSE
#define __SSE2_MATH__ 1
#define __SSE_MATH__ 1
#define __SSE2__ 1
#define __SSE__ 1

You have to set a compiler flag like -msse4

$ gcc -msse4 -dM -E - < /dev/null | grep SSE
#define __SSE4_1__ 1
#define __SSE4_2__ 1
#define __SSE2_MATH__ 1
#define __SSE_MATH__ 1
#define __SSE2__ 1
#define __SSSE3__ 1
#define __SSE__ 1
#define __SSE3__ 1

----------
nosy: +christian.heimes
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31834>
_______________________________________

From report at bugs.python.org  Tue Oct 24 03:26:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 07:26:35 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1508829995.26.0.213398074469.issue31667@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4070

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Tue Oct 24 03:29:34 2017
From: report at bugs.python.org (Ben Finney)
Date: Tue, 24 Oct 2017 07:29:34 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1508756994.09.0.213398074469.issue21720@psf.upfronthosting.co.za>
Message-ID: <20171024072925.z3jnwjzfvgsh23cc@benfinney.id.au>


Ben Finney <ben+python at benfinney.id.au> added the comment:

On 23-Oct-2017, Serhiy Storchaka wrote:
> Is it all with this issue?

I accept Nick's reasoning:

> As a general principle, we don't give value information in type
> errors, since the error is structural rather than value based.

as sufficient to reject my requested improvement to the message.

The change in <URL:https://hg.python.org/cpython/rev/7dd0910e8fbf> is
good enough, IMO.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Tue Oct 24 03:59:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 07:59:24 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1508831964.03.0.213398074469.issue31667@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ef346a2473376c888ff160db9623eaa9871db2ac by Serhiy Storchaka in branch '2.7':
[2.7] bpo-31667: Fix gettext related links. (GH-3860) (#4100)
https://github.com/python/cpython/commit/ef346a2473376c888ff160db9623eaa9871db2ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Tue Oct 24 04:01:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 08:01:17 +0000
Subject: [issue31667] Wrong links in the gettext.NullTranslations class
In-Reply-To: <1506974695.65.0.213398074469.issue31667@psf.upfronthosting.co.za>
Message-ID: <1508832077.23.0.213398074469.issue31667@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31667>
_______________________________________

From report at bugs.python.org  Tue Oct 24 04:02:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 08:02:32 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508832152.96.0.213398074469.issue21720@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Tue Oct 24 04:04:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 08:04:06 +0000
Subject: [issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower
 than reference
In-Reply-To: <1508572631.92.0.213398074469.issue31834@psf.upfronthosting.co.za>
Message-ID: <1508832246.41.0.213398074469.issue31834@psf.upfronthosting.co.za>


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

> AFAIK gcc does not enable SSE3 and SSE4 on X86_64 by default.

Linux now supports multiple variants of the same function, one variant per CPU type, the binding is done when a library is loaded. But I don't know how to implement that :-(

There is target_clones("sse4.1,avx") the function attribute in GCC for example. It compiles a function twice, once for generic CPU, once for SSE4.1.

See also ifunc: "indirect function", "CPU dispatch" or "function resolver".

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31834>
_______________________________________

From report at bugs.python.org  Tue Oct 24 04:29:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 08:29:55 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508833795.47.0.213398074469.issue31810@psf.upfronthosting.co.za>


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


New changeset 87d332dcdbffe8ff60d99f74b1ad241c0967b055 by Victor Stinner in branch 'master':
bpo-31810: Add smelly.py to check exported symbols (#4057)
https://github.com/python/cpython/commit/87d332dcdbffe8ff60d99f74b1ad241c0967b055


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Tue Oct 24 04:46:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 08:46:06 +0000
Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output
In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za>
Message-ID: <1508834766.56.0.213398074469.issue14465@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

My thoughts:

1. Whitespaces are significant in XML. Pretty-printed XML is different from the original XML to an XML parser. For some applications some whitespaces around tags are not significant. But this depends on the application and in different parts of the document whitespaces can have different meaning. For example the document can contain a metadata with insignificant whitespaces and marked up text with significant whitespaces. There is a special attribute named xml:space that can signal the meaning of whitespaces for the part of a document.

https://www.w3.org/TR/xml/#sec-white-space

2. In HTML whitespaces around <P> are insignificant, but whitespaces around <I> are significant. Whitespaces inside <PRE>...</PRE> are significant.

3. If strip whitespaces around tags and insert newlines and indentations, shouldn't we strip whitespaces inside the text context? Or preserve newlines but update indentations?

4. If modify whitespaces on output, it may be worth to add an option to ignore insignificant whitespaces on input.

5. Serialization of ElementTree in the stdlib is much slower than in lxml (see issue25881). Perhaps it should be implemented in C. But it should be kept simple for this. Pretty-printing can be implemented as an outher preprocessing operation (for example the original Eli's code indents the tree in-place: http://effbot.org/zone/element-lib.htm#prettyprint) or as a proxy that indents elements on-fly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14465>
_______________________________________

From report at bugs.python.org  Tue Oct 24 04:48:14 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Oct 2017 08:48:14 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508834894.98.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

What do we do if at some point a C type requires a larger alignment (for example a vector type readable using AVX512 instructions)?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:00:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:00:09 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508835609.98.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

> ubsan complains about unaligned access when structs include "long double". An example error:
> runtime error: member access within misaligned address 0x7f77dbba9798 for type 'struct CDataObject', which requires 16 byte alignment

Can we use memcpy() to prevent such issue?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:01:10 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Oct 2017 09:01:10 +0000
Subject: [issue31106] os.posix_fallocate() generate exception with errno 0
In-Reply-To: <1501686186.83.0.555586832167.issue31106@psf.upfronthosting.co.za>
Message-ID: <1508835670.18.0.213398074469.issue31106@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4071

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31106>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:02:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:02:02 +0000
Subject: [issue31827] Remove os.stat_float_times()
In-Reply-To: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>
Message-ID: <1508835722.97.0.213398074469.issue31827@psf.upfronthosting.co.za>


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


New changeset 01b5aab7bfb11ee5476ef52d24495598cbe7c99a by Victor Stinner in branch 'master':
bpo-31827: Remove os.stat_float_times() (GH-4061)
https://github.com/python/cpython/commit/01b5aab7bfb11ee5476ef52d24495598cbe7c99a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:02:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 09:02:49 +0000
Subject: [issue31106] os.posix_fallocate() generate exception with errno 0
In-Reply-To: <1501686186.83.0.555586832167.issue31106@psf.upfronthosting.co.za>
Message-ID: <1508835769.96.0.213398074469.issue31106@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

????, do you mind to add a NEWS entry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31106>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:06:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:06:08 +0000
Subject: [issue31773] Rewrite _PyTime_GetWinPerfCounter() for _PyTime_t
In-Reply-To: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
Message-ID: <1508835968.19.0.213398074469.issue31773@psf.upfronthosting.co.za>


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

Buildbots seem to be happy, I close the issue.

See my new PEP 564 for the next chapiter of this story ;-)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31773>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:08:34 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 24 Oct 2017 09:08:34 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508836114.15.0.213398074469.issue18835@psf.upfronthosting.co.za>


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

[me]
> This weakens my use case somewhat [...]

I looked at Victor's patch, and thanks to the alignment <= ALIGNMENT
optimization it seems that always using the aligned_alloc() and
aligned_free() versions for a specific pointer is fast. Nice!

So I retract the weakening of my use case (still shame on Microsoft
for not implementing C11). :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:13:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:13:28 +0000
Subject: [issue31731] [2.7] test_io hangs on x86 Gentoo Refleaks 2.7
In-Reply-To: <1507533205.95.0.213398074469.issue31731@psf.upfronthosting.co.za>
Message-ID: <1508836408.98.0.213398074469.issue31731@psf.upfronthosting.co.za>


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

test_io was blocked a second time:

http://buildbot.python.org/all/#/builders/78/builds/3

running: test_io (68517 sec)
running: test_io (68547 sec)
running: test_io (68577 sec)
command interrupted, attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=69935.628661

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31731>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:15:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:15:51 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1508836551.33.0.213398074469.issue31810@psf.upfronthosting.co.za>


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

"make smelly" is now run on Travis CI.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:19:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:19:02 +0000
Subject: [issue31827] Remove os.stat_float_times()
In-Reply-To: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>
Message-ID: <1508836742.89.0.213398074469.issue31827@psf.upfronthosting.co.za>


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

Copy of my comment on the PR: "So, I tried to remove the backward compatibility layer: I modified stat_result[ST_MTIME] to return float rather than int. Problem: it broke test_logging, the code deciding if a log file should be rotated or not.

While I'm not strongly opposed to modify stat_result[ST_MTIME], I prefer to do it in a separated PR. Moreover, we need maybe to emit a DeprecationWarning, or at least deprecate the feature in the doc, before changing the type, no?"

Serhiy's answer: "I agree, it should be done in a separate issue. It needs a special discussion. And maybe this can't be changed."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:19:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:19:23 +0000
Subject: [issue31827] Remove os.stat_float_times()
In-Reply-To: <1508508220.14.0.213398074469.issue31827@psf.upfronthosting.co.za>
Message-ID: <1508836763.7.0.213398074469.issue31827@psf.upfronthosting.co.za>


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

os.stat_float_times() has been removed, I close the issue.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31827>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:22:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:22:24 +0000
Subject: [issue31812] Document PEP 545 (documentation translation) in What's
 New in Python 3.7
In-Reply-To: <1508341337.17.0.213398074469.issue31812@psf.upfronthosting.co.za>
Message-ID: <1508836944.15.0.213398074469.issue31812@psf.upfronthosting.co.za>


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


New changeset 809d173c2005ed76f5b6cb178a0cce3f88121883 by Victor Stinner (Julien Palard) in branch 'master':
bpo-31812: Add documentation translations to What's New in Python 3.7. (GH-4064)
https://github.com/python/cpython/commit/809d173c2005ed76f5b6cb178a0cce3f88121883


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31812>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:22:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:22:53 +0000
Subject: [issue31812] Document PEP 545 (documentation translation) in What's
 New in Python 3.7
In-Reply-To: <1508341337.17.0.213398074469.issue31812@psf.upfronthosting.co.za>
Message-ID: <1508836973.4.0.213398074469.issue31812@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31812>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:23:23 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 24 Oct 2017 09:23:23 +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: <1508837003.19.0.213398074469.issue23699@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

Both tp_richcompare and PyObject_RichCompareBool have op as the last argument:

https://docs.python.org/3/c-api/object.html#c.PyObject_RichCompareBool
https://docs.python.org/3/c-api/typeobj.html?highlight=tp_richcompare#c.PyTypeObject.tp_richcompare

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:23:32 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:23:32 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508837012.73.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know."

Do you still think that we need to modify time.clock() rather than deprecating it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:24:18 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:24:18 +0000
Subject: [issue31674] Buildbots: random "Failed to connect to github.com port
 443: Connection timed out" errors
In-Reply-To: <1507031049.66.0.213398074469.issue31674@psf.upfronthosting.co.za>
Message-ID: <1508837058.02.0.213398074469.issue31674@psf.upfronthosting.co.za>


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

I didn't see the failure recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31674>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:26:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:26:10 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1508837170.66.0.213398074469.issue31430@psf.upfronthosting.co.za>


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

Any update on this bug?

The "AMD64 Windows10 2.7" buildbot is still broken:
http://buildbot.python.org/all/#/builders/96

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:27:09 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:27:09 +0000
Subject: [issue31227] regrtest: reseed random with the same seed before
 running a test file
In-Reply-To: <1502983924.76.0.0545413601956.issue31227@psf.upfronthosting.co.za>
Message-ID: <1508837229.64.0.213398074469.issue31227@psf.upfronthosting.co.za>


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

I didn't get a strong +1 on the issue and I'm not convinced myself by my approach. Moreover, Refleaks buildbots now seem to be reliable thanks to other fixes. For all these reasons, I close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31227>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:27:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:27:23 +0000
Subject: [issue31227] regrtest: reseed random with the same seed before
 running a test file
In-Reply-To: <1502983924.76.0.0545413601956.issue31227@psf.upfronthosting.co.za>
Message-ID: <1508837243.13.0.213398074469.issue31227@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31227>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:29:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:29:25 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508837365.08.0.213398074469.issue31174@psf.upfronthosting.co.za>


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

"test_tools leaked (...)" still occurs randomly on 3.6 and 3.x Gentoo buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:37:46 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:37:46 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508837866.66.0.213398074469.issue31174@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4072
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:38:50 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 09:38:50 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508837930.31.0.213398074469.issue31174@psf.upfronthosting.co.za>


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

My previous attempt, PR 3059, was a a very generic fix, but my bpo-31227 idea was rejected.

I proposed a new idea, PR 4102, which is restricted to this specific issue:
"test_unparse.DirectoryTestCase now stores the names sample to always
test the same files. It prevents false alarms when hunting reference
leaks."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 05:46:29 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 24 Oct 2017 09:46:29 +0000
Subject: [issue28281] Remove year limits from calendar
In-Reply-To: <1474922646.39.0.781731359123.issue28281@psf.upfronthosting.co.za>
Message-ID: <1508838389.75.0.213398074469.issue28281@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hello Mark, 

Would you be able to prepare a pull request on GitHub for your patch?

Thanks!

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28281>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:21:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:21:07 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508840467.45.0.213398074469.issue30768@psf.upfronthosting.co.za>


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

interrupted_lock.py: test threading.Lock.acquire(timeout=1.0) with SIGALRM sent every 1 ms (so up to 1000 times in total). Example:

haypo at selma$ ./python interrupted_lock.py 
acquire(timeout=1.0) took 1.0 seconds and got 1000 signals

Oh, in fact, threading.Lock.acquire(timeout=1.0) already recomputes the timeout when interrupted.

In Python stdlib, PyThread_acquire_lock_timed() is only called from one place with intr_flag=0: faulthandler watchdog thread, but this thread blocks all signals:

    /* we don't want to receive any signal */
    sigfillset(&set);
    pthread_sigmask(SIG_SETMASK, &set, NULL);

----------
Added file: https://bugs.python.org/file47233/interrupted_lock.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:28:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:28:03 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508840883.72.0.213398074469.issue30768@psf.upfronthosting.co.za>


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

Ah, I found another caller of PyThread_acquire_lock_timed() with a timeout > 0 and intr_flag=0: _enter_buffered_busy() of Modules/_io/bufferedio.c:

        /* When finalizing, we don't want a deadlock to happen with daemon
         * threads abruptly shut down while they owned the lock.
         * Therefore, only wait for a grace period (1 s.).
         * Note that non-daemon threads have already exited here, so this
         * shouldn't affect carefully written threaded I/O code.
         */
        st = PyThread_acquire_lock_timed(self->lock, (PY_TIMEOUT_T)1e6, 0);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:28:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:28:11 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508840891.01.0.213398074469.issue30768@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4073
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:29:12 2017
From: report at bugs.python.org (Lele Gaifax)
Date: Tue, 24 Oct 2017 10:29:12 +0000
Subject: [issue27645] Supporting native backup facility of SQLite
In-Reply-To: <1469728098.24.0.732586701981.issue27645@psf.upfronthosting.co.za>
Message-ID: <1508840952.27.0.213398074469.issue27645@psf.upfronthosting.co.za>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

Reasonable and quite simple to implement: done in commit https://github.com/lelit/cpython/commit/960303f9eb394e2ba91d10e5e674997a48811ac2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27645>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:30:17 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:30:17 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508841017.56.0.213398074469.issue30768@psf.upfronthosting.co.za>


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

I wrote PR 4103 to fix the pthread+semaphore implementation of PyThread_acquire_lock_timed().

Apply PR 4103, apply attached test.patch, recompile Python, and run interrupted_lock.py to test the PR. Result:

haypo at selma$ ./python interrupted_lock.py 
acquire(timeout=1.0) took 1.0 seconds and got 911 signals

----------
Added file: https://bugs.python.org/file47234/test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:31:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:31:59 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508841119.01.0.213398074469.issue30768@psf.upfronthosting.co.za>


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

To check if you are using pthread+semaphore, use:

haypo at selma$ ./python -c 'import sys; print(sys.thread_info)'
sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.25')

Here you have pthread+semaphore. It's Fedora 26 running Linux kernel 4.13.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:33:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:33:38 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508841218.59.0.213398074469.issue31174@psf.upfronthosting.co.za>


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


New changeset 8e482bea21cb942804234e36d3c6c896aabd32da by Victor Stinner in branch 'master':
bpo-31174: Fix test_tools.test_unparse (#4102)
https://github.com/python/cpython/commit/8e482bea21cb942804234e36d3c6c896aabd32da


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:33:59 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Oct 2017 10:33:59 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508841239.58.0.213398074469.issue31174@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4074

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:36:49 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 10:36:49 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508841409.11.0.213398074469.issue31174@psf.upfronthosting.co.za>


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

Python 2.7 is not affected. Even if Python 2.7 has Demo/parser/test_unparse.py, this test is not part of the Python test suite, and it doesn't use random.sample(names, 10).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 06:41:13 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Oct 2017 10:41:13 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508841673.69.0.213398074469.issue31845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Huh, it appears the tests for these features are relying solely on the command line options, and not checking that the environment variables are also setting the flags properly. We should be able to account for that omission with a single new test in `test_cmd_line` that sets every relevant environment variable and checks for the expected `sys.flags` contents.

As far as what's actually going wrong goes, it's this sequence of events in Py_Main:

    _Py_InitializeCore(&core_config);
    ... other code ...
    apply_command_line_and_environment(&cmdline);

_Py_InitializeCore is setting the internal flags appropriately based on the runtime environment, but then Py_Main is stomping over those environmental settings with the settings from the command line.

Historically, these operations happened the other way around, so it was solely up to the code reading the environment variables to ensure they played nice with each other. Now the command line processing logic needs to be updated to also ensure that it only ever increases these values and never reduces them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Tue Oct 24 07:18:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 11:18:06 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508843886.58.0.213398074469.issue31174@psf.upfronthosting.co.za>


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


New changeset d8f78a1fbc0a34224289d436ad67f608fa553f0c by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-31174: Fix test_tools.test_unparse (GH-4102) (#4104)
https://github.com/python/cpython/commit/d8f78a1fbc0a34224289d436ad67f608fa553f0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 07:18:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 11:18:27 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1508843907.1.0.213398074469.issue31174@psf.upfronthosting.co.za>


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

The bug should now be fixed.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Tue Oct 24 07:28:00 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Oct 2017 11:28:00 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508844480.46.0.213398074469.issue31845@psf.upfronthosting.co.za>


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


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Tue Oct 24 07:46:36 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 Oct 2017 11:46:36 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508845596.26.0.213398074469.issue31845@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4075
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:13:37 2017
From: report at bugs.python.org (Tim)
Date: Tue, 24 Oct 2017 12:13:37 +0000
Subject: [issue31859] sharedctypes.RawArray initialization
Message-ID: <1508847217.79.0.213398074469.issue31859@psf.upfronthosting.co.za>


New submission from Tim <tim.elberfeld at uantwerpen.be>:

In the initialization of a new `RawArray` the `size_or_initializer` parameter is tested for being an instance of `int`. When passing something like numpy.int64 here, the code crashes, because it does not recognize this as an integer. The workaround is to cast to int(). Wouldn't it be nicer to compare to types.IntType to allow for custom integer types?

def RawArray(typecode_or_type, size_or_initializer):
    '''
    Returns a ctypes array allocated from shared memory
    '''
    type_ = typecode_to_type.get(typecode_or_type, typecode_or_type)
-    if isinstance(size_or_initializer, int):
+    if size_or_initializer is IntType:

----------
messages: 304902
nosy: meetaig
priority: normal
severity: normal
status: open
title: sharedctypes.RawArray initialization
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31859>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:42:38 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 24 Oct 2017 12:42:38 +0000
Subject: [issue30639] inspect.getfile(obj) calls object repr on failure
In-Reply-To: <1497275646.73.0.340946386464.issue30639@psf.upfronthosting.co.za>
Message-ID: <1508848958.89.0.213398074469.issue30639@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset e968bc735794a7123f28f26d68fdf5dc8c845280 by Yury Selivanov (Thomas Kluyver) in branch 'master':
bpo-30639: Lazily compute repr for error (#2132)
https://github.com/python/cpython/commit/e968bc735794a7123f28f26d68fdf5dc8c845280


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30639>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:43:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 12:43:05 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508848985.47.0.213398074469.issue20180@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems Raymond have changed his mind about using Argument Clinic in itertools (msg302908). Tal, do you mind to update your itertools patch and create a pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:43:35 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 24 Oct 2017 12:43:35 +0000
Subject: [issue30639] inspect.getfile(obj) calls object repr on failure
In-Reply-To: <1497275646.73.0.340946386464.issue30639@psf.upfronthosting.co.za>
Message-ID: <1508849015.85.0.213398074469.issue30639@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thank you, Thomas.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30639>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:45:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 12:45:23 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1508849123.53.0.213398074469.issue20182@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tail, do you mind to update your patches and create pull requests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:45:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 12:45:40 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1508849140.31.0.213398074469.issue20182@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg304906

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:45:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 12:45:48 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1508849148.52.0.213398074469.issue20182@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tal, do you mind to update your patches and create pull requests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Tue Oct 24 08:51:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 12:51:13 +0000
Subject: [issue31585] Refactor the enumerate.__next__ implementation
In-Reply-To: <1506403646.08.0.860843396895.issue31585@psf.upfronthosting.co.za>
Message-ID: <1508849473.66.0.213398074469.issue31585@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Added a patch for history.

----------
Added file: https://bugs.python.org/file47235/enum_next.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31585>
_______________________________________

From report at bugs.python.org  Tue Oct 24 09:20:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 13:20:40 +0000
Subject: [issue31860] IDLE: Make font sample editable
Message-ID: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed patch makes the font sample in IDLE font configuration dialog editable. This allows users to test fonts with arbitrary samples.

----------
assignee: terry.reedy
components: IDLE
messages: 304909
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Make font sample editable
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Tue Oct 24 09:23:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 13:23:25 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1508851405.28.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4076
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Tue Oct 24 09:26:15 2017
From: report at bugs.python.org (Davide Rizzo)
Date: Tue, 24 Oct 2017 13:26:15 +0000
Subject: [issue31861] aiter() and anext() built-in functions
Message-ID: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

PEP 525 suggested that adding aiter() and anext() would need to wait until async __aiter__ is dropped in 3.7. Issue 31709 solved that, so now it would be possible to add them.

----------
components: Library (Lib)
messages: 304910
nosy: davide.rizzo
priority: normal
severity: normal
status: open
title: aiter() and anext() built-in functions
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Oct 24 10:10:46 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Oct 2017 14:10:46 +0000
Subject: [issue30817] Abort in PyErr_PrintEx() when no memory
In-Reply-To: <1498832371.19.0.0580869338001.issue30817@psf.upfronthosting.co.za>
Message-ID: <1508854246.33.0.213398074469.issue30817@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +4077

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30817>
_______________________________________

From report at bugs.python.org  Tue Oct 24 10:31:27 2017
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 24 Oct 2017 14:31:27 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1508855487.9.0.213398074469.issue31430@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Tue Oct 24 10:34:25 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Oct 2017 14:34:25 +0000
Subject: [issue31834] BLAKE2: the (pure) SSE2 impl forced on x86_64 is slower
 than reference
In-Reply-To: <1508829904.18.0.213398074469.issue31834@psf.upfronthosting.co.za>
Message-ID: <1508855661.2423547.1149340208.578CA372@webmail.messagingengine.com>


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

On Tue, Oct 24, 2017, at 00:25, Christian Heimes wrote:
> 
> Christian Heimes <lists at cheimes.de> added the comment:
> 
> I'm pretty sure that your PR has disabled all SSE optimizations. AFAIK
> gcc does not enable SSE3 and SSE4 on X86_64 by default.
> 
> $ gcc -dM -E - < /dev/null | grep SSE
> #define __SSE2_MATH__ 1
> #define __SSE_MATH__ 1
> #define __SSE2__ 1
> #define __SSE__ 1

Before this patch, this would cause blake2b.c to use slow SSE2 only
instruction, though, right?

It seems to me this represents an improvement or the status quo in all
cases. With no extra GCC flags, the reference implementation is used
rather than a slow SSE2 implementation. If extra -m flags are in CFLAGS,
the fastest implementation for the target is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31834>
_______________________________________

From report at bugs.python.org  Tue Oct 24 10:41:45 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Oct 2017 14:41:45 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508856105.05.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

My suggestion would be to pass alignof(type) into the allocator via macro. Then the allocator could at least assert it's providing good enough alignment if not provide the correct alignment.

I believe 16-byte alignment is special because it's glibc's malloc's default. So "normal" code shouldn't really be expecting anything better than 16-byte alignment. Code with higher alignment requirements will have to use APIs like the one proposed in #18835.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 10:42:38 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Oct 2017 14:42:38 +0000
Subject: [issue30817] Abort in PyErr_PrintEx() when no memory
In-Reply-To: <1498832371.19.0.0580869338001.issue30817@psf.upfronthosting.co.za>
Message-ID: <1508856158.82.0.213398074469.issue30817@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:


New changeset d5d79545b73110b2f4c2b66d150409514e2ca8e0 by xdegaye in branch '3.6':
[3.6] bpo-30817: Fix PyErr_PrintEx() when no memory (GH-2526). (#4107)
https://github.com/python/cpython/commit/d5d79545b73110b2f4c2b66d150409514e2ca8e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30817>
_______________________________________

From report at bugs.python.org  Tue Oct 24 10:44:13 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Oct 2017 14:44:13 +0000
Subject: [issue30817] Abort in PyErr_PrintEx() when no memory
In-Reply-To: <1498832371.19.0.0580869338001.issue30817@psf.upfronthosting.co.za>
Message-ID: <1508856253.27.0.213398074469.issue30817@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30817>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:08:56 2017
From: report at bugs.python.org (Marcel Plch)
Date: Tue, 24 Oct 2017 15:08:56 +0000
Subject: [issue31862] Port the standard library to PEP 489 multiphase
 initialization
Message-ID: <1508857736.11.0.213398074469.issue31862@psf.upfronthosting.co.za>


New submission from Marcel Plch <gmarcel.plch at gmail.com>:

PEP 489 introduced multiphase initialization of extension and built-in modules.
Now, almost no module in the standard library supports this feature. This should be improved to prepare Python for better testing of subinterpreters.

Many benefits of PEP 489 don't apply to stdlib modules. However, the PEP effectively says that by using multi-phase init, the module author "promises" that the module is "subinterpreter-friendly" [0]. So, when porting, each module should be checked that it e.g. doesn't use mutable process-global state.

I'd like to port stdlib to multi-phase init, starting with the easier modules, to:
    - get familiar with contributing to CPython,
    - check and track which modules are already "subinterpreter-friendly", and
    - figure out how and where PEP 489 is lacking (beyond what is discussed in the PEP itself).


[0]: https://www.python.org/dev/peps/pep-0489/#subinterpreters-and-interpreter-reloading

----------
components: Extension Modules
messages: 304914
nosy: Dormouse759, encukou, ncoghlan
priority: normal
severity: normal
status: open
title: Port the standard library to PEP 489 multiphase initialization
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31862>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:10:08 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 24 Oct 2017 15:10:08 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1508857808.61.0.213398074469.issue28936@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think this is very minor but if you two can agree that the code is right I think it's a nice little improvement, and I like that that particular test's usefulness is restored.


PS. Long-term we should really build error recovery into our antiquated parser and report as many errors as we can, without cascading. But that's probably a Python 4 project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:15:52 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 24 Oct 2017 15:15:52 +0000
Subject: [issue31862] Port the standard library to PEP 489 multiphase
 initialization
In-Reply-To: <1508857736.11.0.213398074469.issue31862@psf.upfronthosting.co.za>
Message-ID: <1508858152.49.0.213398074469.issue31862@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

FWIW, Marcel is an intern in my team, tasked to learn CPython internals by trying to improve subinterpreter support. If I don't comment on his issues it's because we discussed privately beforehand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31862>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:18:34 2017
From: report at bugs.python.org (Marcel Plch)
Date: Tue, 24 Oct 2017 15:18:34 +0000
Subject: [issue31862] Port the standard library to PEP 489 multiphase
 initialization
In-Reply-To: <1508857736.11.0.213398074469.issue31862@psf.upfronthosting.co.za>
Message-ID: <1508858314.82.0.213398074469.issue31862@psf.upfronthosting.co.za>


Change by Marcel Plch <gmarcel.plch at gmail.com>:


----------
keywords: +patch
pull_requests: +4078
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31862>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:18:43 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Oct 2017 15:18:43 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508858323.04.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

> My suggestion would be to pass alignof(type) into the allocator via macro.

Do you mean using some new PyMem_ function?  Or as as new tp_ field on the type declaration?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:19:04 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Oct 2017 15:19:04 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508858344.9.0.213398074469.issue27987@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:33:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 15:33:57 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508859237.58.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

What matters when a Python object is allocated? The start of the PyObject structure, or the start of the PyGC_Head structure? Would it be possible to align the PyObject start?

The simplest option is to store data which needs to be aligned in a second memory block allocated by PyMem_AlignedAlloc().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:35:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 15:35:23 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508859323.74.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

Change by Antoine Pitrou: "versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6"

The undefined behaviour exists and should be fixed in Python 2.7 and 3.6, no? Can we use memcpy()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:46:53 2017
From: report at bugs.python.org (Akos Kiss)
Date: Tue, 24 Oct 2017 15:46:53 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
Message-ID: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>


New submission from Akos Kiss <akosthekiss at gmail.com>:

I've been working with various approaches for running and terminating subprocesses on Windows and I've obtained surprisingly different results if I used different modules and ways of termination. Here is the script I wrote, it uses the `subprocess` and the `multiprocessing` modules for starting new subprocesses, and process termination is performed either by the modules' own `terminate` functions or by `os.kill`.

```py
import multiprocessing
import os
import signal
import subprocess
import sys
import time

def kill_with_os_kill(proc):
    print('kill with os.kill(pid,SIGTERM)')
    os.kill(proc.pid, signal.SIGTERM)

def kill_with_terminate(proc):
    print('kill child with proc.terminate()')
    proc.terminate()

def run_and_kill_subprocess(killfn, procarg):
    print('run subprocess child with %s' % procarg)
    with subprocess.Popen([sys.executable, __file__, procarg]) as proc:
        time.sleep(1)
        killfn(proc)
        proc.wait()
    print('child terminated with %s' % proc.returncode)

def run_and_kill_multiprocessing(killfn, procarg):
    print('run multiprocessing child with %s' % procarg)
    proc = multiprocessing.Process(target=childmain, args=(procarg,))
    proc.start()
    time.sleep(1)
    killfn(proc)
    proc.join()
    print('child terminated with %s' % proc.exitcode)

def childmain(arg):
    print('child process started with %s' % arg)
    while True:
        pass

if __name__ == '__main__':
    if len(sys.argv) < 2:
        print('parent process started')
        run_and_kill_subprocess(kill_with_os_kill, 'subprocess-oskill')
        run_and_kill_subprocess(kill_with_terminate, 'subprocess-terminate')
        run_and_kill_multiprocessing(kill_with_os_kill, 'multiprocessing-oskill')
        run_and_kill_multiprocessing(kill_with_terminate, 'multiprocessing-terminate')
    else:
        childmain(sys.argv[1])
```

On macOS, everything works as expected (and I think that Linux will behave alike):

```
$ python3 killtest.py 
parent process started
run subprocess child with subprocess-oskill
child process started with subprocess-oskill
kill with os.kill(pid,SIGTERM)
child terminated with -15
run subprocess child with subprocess-terminate
child process started with subprocess-terminate
kill child with proc.terminate()
child terminated with -15
run multiprocessing child with multiprocessing-oskill
child process started with multiprocessing-oskill
kill with os.kill(pid,SIGTERM)
child terminated with -15
run multiprocessing child with multiprocessing-terminate
child process started with multiprocessing-terminate
kill child with proc.terminate()
child terminated with -15
```

But on Windows, I got:

```
>py -3 killtest.py
parent process started
run subprocess child with subprocess-oskill
child process started with subprocess-oskill
kill with os.kill(pid,SIGTERM)
child terminated with 15
run subprocess child with subprocess-terminate
child process started with subprocess-terminate
kill child with proc.terminate()
child terminated with 1
run multiprocessing child with multiprocessing-oskill
child process started with multiprocessing-oskill
kill with os.kill(pid,SIGTERM)
child terminated with 15
run multiprocessing child with multiprocessing-terminate
child process started with multiprocessing-terminate
kill child with proc.terminate()
child terminated with -15
```

Notes:
- On Windows with `os.kill(pid, sig)`, "sig will cause the process to be unconditionally killed by the TerminateProcess API, and the exit code will be set to sig." I.e., it is not possible to detect on Windows whether a process was terminated by a signal or it exited properly, because `kill` does not actually raise a signal and no Windows API allows to differentiate between proper or forced termination.
- The `multiprocessing` module has a workaround for this by terminating the process with a designated exit code (`TERMINATE = 0x10000`) and checking for that value afterwards, rewriting it to `-SIGTERM` if found. The related documentation is a bit misleading, as `exitcode` is meant to have "negative value -N [which] indicates that the child was terminated by signal N" -- however, if the process was indeed killed with `SIGTERM` (and not via `terminate`), then `exitcode` will be `SIGTERM` and not `-SIGTERM` (see above). (The documentation of `terminate` does not clarify the situation much by stating that "on Windows TerminateProcess() is used", since it does not mention the special exit code -- and well, it's not even a signal after all, so it's not obvious whether negative or positive exit code is to be expected.)
- The `subprocess` module choses the quite arbitrary exit code of 1 and documents that "negative value -N indicates that the child was terminated by signal N" is POSIX only, not mentioning anything about what to expect on Windows.

Long story short: on Windows, the observable exit code of a forcibly terminated child process is quite inconsistent even across standard modules and termination methods, unlike on other (Linux/macOS) platforms. I think that having results consistent with `os.kill(,SIGTERM)` would be desirable even if that means non-negative values.

I'm willing to post a PR if the issue is deemed to be valid.

----------
components: Library (Lib), Windows
messages: 304920
nosy: Akos Kiss, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Inconsistent returncode/exitcode for terminated child processes on Windows
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Tue Oct 24 11:54:13 2017
From: report at bugs.python.org (Dmitry Kazakov)
Date: Tue, 24 Oct 2017 15:54:13 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1508860453.27.0.213398074469.issue31299@psf.upfronthosting.co.za>


Dmitry Kazakov <waultah at gmail.com> added the comment:

Ping. (this issue needs a decision on ignore_modules vs filter callback, and/or patch review)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:02:43 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Oct 2017 16:02:43 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508860963.66.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

> Can we use memcpy()?

Hmm, perhaps.  Do you want to try it out (and measure any performance degradation)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:10:26 2017
From: report at bugs.python.org (Davide Rizzo)
Date: Tue, 24 Oct 2017 16:10:26 +0000
Subject: [issue31861] aiter() and anext() built-in functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1508861426.25.0.213398074469.issue31861@psf.upfronthosting.co.za>


Change by Davide Rizzo <sorcio at gmail.com>:


----------
nosy: +gvanrossum, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:17:13 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 24 Oct 2017 16:17:13 +0000
Subject: [issue31861] aiter() and anext() built-in functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1508861833.77.0.213398074469.issue31861@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Guido, do we need a PEP to add aiter() and anext() builtins?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:24:34 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 24 Oct 2017 16:24:34 +0000
Subject: [issue31861] aiter() and anext() built-in functions
In-Reply-To: <1508861833.77.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+NwNUk+6bcRzdTHenSFVwCv7NUAJ=0XK2mgmqu973kGQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

> do we need a PEP to add aiter() and anext() builtins?

No, just this tracker issue, a PR and a reviewer. (Sorry, I can't review
CPython code myself any more.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:24:36 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 24 Oct 2017 16:24:36 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508862276.24.0.213398074469.issue27987@psf.upfronthosting.co.za>


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

Since we have "#define PYMEM_FUNCS PYOBJ_FUNCS", I think extensions that
use PyMem_Malloc() also won't get the glibc max_align_t alignment.

But guess technically they should.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:25:26 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 24 Oct 2017 16:25:26 +0000
Subject: [issue31861] aiter() and anext() built-in functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1508862326.44.0.213398074469.issue31861@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> No, just this tracker issue, a PR and a reviewer. (Sorry, I can't review
CPython code myself any more.)

Alright, I'll work on a PR after PEP 55x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:36:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 16:36:19 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1508862979.4.0.213398074469.issue31664@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset eab3ff72ebe79416cc032b8508ae13332955a157 by Serhiy Storchaka in branch 'master':
bpo-31664: Add support for the Blowfish method in crypt. (#3854)
https://github.com/python/cpython/commit/eab3ff72ebe79416cc032b8508ae13332955a157


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:38:26 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 16:38:26 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1508863106.61.0.213398074469.issue31664@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:43:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 16:43:34 +0000
Subject: [issue14518] Add bcrypt $2a$ to crypt.py
In-Reply-To: <1333741347.69.0.597224923936.issue14518@psf.upfronthosting.co.za>
Message-ID: <1508863414.48.0.213398074469.issue14518@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The support of the Blowfish hashing (prefix '$2a$') has been added in issue31664.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: needs patch -> resolved
status: pending -> closed
superseder:  -> Add support of new crypt methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14518>
_______________________________________

From report at bugs.python.org  Tue Oct 24 12:47:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 16:47:42 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1508863662.45.0.213398074469.issue25287@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

issue31664 fixes test_crypt in 3.7. In other versions the test should be just skipped on OpenBSD. Blowfish is the only method supported on OpenBSD, but it was not supported by the Python's crypt module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25287>
_______________________________________

From report at bugs.python.org  Tue Oct 24 13:17:14 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 24 Oct 2017 17:17:14 +0000
Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in
 edge cases
In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za>
Message-ID: <1508865434.91.0.213398074469.issue28292@psf.upfronthosting.co.za>


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


New changeset fdd9b217c60b454ac6a82f02c8b0b551caeac88b by Alexander Belopolsky in branch 'master':
Closes bpo-28292: Implemented Calendar.itermonthdays3() and itermonthdays4(). (#4079)
https://github.com/python/cpython/commit/fdd9b217c60b454ac6a82f02c8b0b551caeac88b


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28292>
_______________________________________

From report at bugs.python.org  Tue Oct 24 13:32:50 2017
From: report at bugs.python.org (Tal Einat)
Date: Tue, 24 Oct 2017 17:32:50 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508866370.29.0.213398074469.issue20180@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Id be happy to update the itertools patch.

I haven't been following AC work for quite a while. I would expect this to entail:

1. applying the patch to the master branch
2. merging any conflicts
3. running the clinic.py script again
4. review the output and compare it to the previous output to make sure things look okay

Would you also prefer this in the form of a GitHub PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Oct 24 13:35:07 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 24 Oct 2017 17:35:07 +0000
Subject: [issue28281] Remove year limits from calendar
In-Reply-To: <1474922646.39.0.781731359123.issue28281@psf.upfronthosting.co.za>
Message-ID: <1508866507.38.0.213398074469.issue28281@psf.upfronthosting.co.za>


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


----------
pull_requests: +4079
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28281>
_______________________________________

From report at bugs.python.org  Tue Oct 24 13:37:01 2017
From: report at bugs.python.org (Tal Einat)
Date: Tue, 24 Oct 2017 17:37:01 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1508866621.76.0.213398074469.issue20182@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I'd be happy to update the patches.

I asked for a bit of clarification on what this entails in msg304931 on issue #20180, once that's clear I'll do the same for these patches and create PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Tue Oct 24 13:37:43 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 24 Oct 2017 17:37:43 +0000
Subject: [issue28281] Remove year limits from calendar
In-Reply-To: <1474922646.39.0.781731359123.issue28281@psf.upfronthosting.co.za>
Message-ID: <1508866663.21.0.213398074469.issue28281@psf.upfronthosting.co.za>


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

I submitted Mark's patch unchanged as PR 4109.  If we don't hear from Mark, I will address my own comments and merge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28281>
_______________________________________

From report at bugs.python.org  Tue Oct 24 14:25:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 18:25:14 +0000
Subject: [issue31702] Allow to specify the number of rounds for SHA-* hashing
 in crypt
In-Reply-To: <1507206772.04.0.213398074469.issue31702@psf.upfronthosting.co.za>
Message-ID: <1508869514.01.0.213398074469.issue31702@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4080
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31702>
_______________________________________

From report at bugs.python.org  Tue Oct 24 14:38:20 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 24 Oct 2017 18:38:20 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1508870300.25.0.213398074469.issue9305@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Would one of the original authors of the patches like to create a GitHub pull request for this issue?

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Tue Oct 24 14:45:49 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 18:45:49 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508870749.58.0.213398074469.issue20180@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

All correct. The final patch should be in the form of GitHub PR.

Don't specify the self parameter explicitly, just rename the corresponding variable. The rest of the patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Oct 24 14:57:25 2017
From: report at bugs.python.org (Tal Einat)
Date: Tue, 24 Oct 2017 18:57:25 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508871445.97.0.213398074469.issue20180@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

What about islice? Does AC now support complex enough signatures to support it? If not, should I leave the comment as is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Oct 24 15:10:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 19:10:52 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1508872252.04.0.213398074469.issue25287@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4081
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25287>
_______________________________________

From report at bugs.python.org  Tue Oct 24 15:23:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 19:23:19 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508872999.91.0.213398074469.issue20180@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Keep islice() non-converted. For the r parameter of permutations() use "r: object = None".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:11:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:11:48 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1508875908.66.0.213398074469.issue25287@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f52dff611cff2fb9e90340b4787eda50ab2d40c6 by Serhiy Storchaka in branch '3.6':
bpo-25287: Backport new tests for crypt and skip test_crypt on OpenBSD. (#4111)
https://github.com/python/cpython/commit/f52dff611cff2fb9e90340b4787eda50ab2d40c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25287>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:20:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:20:48 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1508876448.11.0.213398074469.issue25287@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4082

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25287>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:31:44 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:31:44 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1508877104.25.0.213398074469.issue31690@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3557b05c5a7dfd7d97ddfd3b79aefd53d25e5132 by Serhiy Storchaka in branch 'master':
bpo-31690: Allow the inline flags "a", "L", and "u" to be used as group flags for RE. (#3885)
https://github.com/python/cpython/commit/3557b05c5a7dfd7d97ddfd3b79aefd53d25e5132


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:33:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:33:52 +0000
Subject: [issue31690] Make RE "a", "L" and "u" inline flags local
In-Reply-To: <1507125776.04.0.213398074469.issue31690@psf.upfronthosting.co.za>
Message-ID: <1508877232.5.0.213398074469.issue31690@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31690>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:35:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:35:24 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1508877324.38.0.213398074469.issue25287@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 04c0a4038e8764f742de8505600b8ee97ee50776 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-25287: Backport new tests for crypt and skip test_crypt on OpenBSD. (GH-4111). (#4112)
https://github.com/python/cpython/commit/04c0a4038e8764f742de8505600b8ee97ee50776


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25287>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:36:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:36:06 +0000
Subject: [issue25287] test_crypt fails on OpenBSD
In-Reply-To: <1443682191.0.0.229033947807.issue25287@psf.upfronthosting.co.za>
Message-ID: <1508877366.54.0.213398074469.issue25287@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25287>
_______________________________________

From mal at egenix.com  Tue Oct 24 16:40:44 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 24 Oct 2017 22:40:44 +0200
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508837012.73.0.213398074469.issue31803@psf.upfronthosting.co.za>
References: <1508837012.73.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <4a8c1531-4042-0d64-d07e-b59a8e0de91b@egenix.com>

On 24.10.2017 11:23, STINNER Victor wrote:
> 
> Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know."
> 
> Do you still think that we need to modify time.clock() rather than deprecating it?

Yes, to avoid yet another Python 2/3 difference. It should be
replaced with the appropriate variant on Windows
and non-Windows platforms. From Serhiy's response that's
time.process_time() on non-Windows platforms and time.perf_counter()
on Windows.

The documentation can point to the new functions and recommend
these over time.clock().

-- 
Marc-Andre Lemburg
eGenix.com

From report at bugs.python.org  Tue Oct 24 16:40:58 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 24 Oct 2017 20:40:58 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508837012.73.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <4a8c1531-4042-0d64-d07e-b59a8e0de91b@egenix.com>


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

On 24.10.2017 11:23, STINNER Victor wrote:
> 
> Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know."
> 
> Do you still think that we need to modify time.clock() rather than deprecating it?

Yes, to avoid yet another Python 2/3 difference. It should be
replaced with the appropriate variant on Windows
and non-Windows platforms. From Serhiy's response that's
time.process_time() on non-Windows platforms and time.perf_counter()
on Windows.

The documentation can point to the new functions and recommend
these over time.clock().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:48:33 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 24 Oct 2017 20:48:33 +0000
Subject: [issue31702] Allow to specify the number of rounds for SHA-* hashing
 in crypt
In-Reply-To: <1507206772.04.0.213398074469.issue31702@psf.upfronthosting.co.za>
Message-ID: <1508878113.71.0.213398074469.issue31702@psf.upfronthosting.co.za>


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

I'd raise a ValueError in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31702>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:53:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:53:39 +0000
Subject: [issue28503] [Patch] '_crypt' module: fix implicit declaration of
 crypt(), use crypt_r() where available
In-Reply-To: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za>
Message-ID: <1508878419.04.0.213398074469.issue28503@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the performance of crypt_r() in comparison with crypt()?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28503>
_______________________________________

From report at bugs.python.org  Tue Oct 24 16:55:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Oct 2017 20:55:02 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1508878502.79.0.213398074469.issue25172@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Tue Oct 24 18:56:14 2017
From: report at bugs.python.org (Geoff Kuenning)
Date: Tue, 24 Oct 2017 22:56:14 +0000
Subject: [issue31864] datetime violates Postel's law
Message-ID: <1508885774.85.0.213398074469.issue31864@psf.upfronthosting.co.za>


New submission from Geoff Kuenning <geoff at cs.hmc.edu>:

The datetime package is too eager to reject nonconforming VCALENDAR-format files.  The particular issue I encountered is related to time zones.  RFC 5545 clearly states that the DTSTART field is required.  However, there are situations where DTSTART isn't strictly necessary because the zone in question doesn't observe daylight-savings time and never has.

For example, I have a VCALENDAR file that was generated by a program that omits DTSTART for such zones.  Here's an example:

BEGIN:VTIMEZONE
TZID:America/Phoenix
X-LIC-LOCATION:America/Phoenix
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:Ariz
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0700
TZNAME:Ariz
END:STANDARD
END:VTIMEZONE

Clearly, this file violates RFC 5445, and I have reported that fact to the program's maintainer (who will fix the problem soon).  Nevertheless, feeding an ICS file to datetime._parse_rfc with this error causes a ValueError exception, which makes the VCALENDAR file unreadable.

In keeping with Postel's law ("Be conservative in what you do, be liberal in what you accept from others"), _parse_rfc should attempt to accept VCALENDAR files whenever it is possible to make sense of them.  Thus, for example:

    if not founddtstart:
        rrulelines.append('DTSTART:19000101T020000')

The above could be improved a bit, for example by still rejecting entries in which the standard and daylight sections had different offsets (although even then it seems valid to assume a DTSTART in the distant past).

Although the dtstart issue is the one that prompted this report, I also noticed the following in _parse_rfc:

    if name == "BEGIN":
        if value in ("STANDARD", "DAYLIGHT"):
            # Process component
            pass
        else:
            raise ValueError("unknown component: "+value)

Again, there's an opportunity to be more robust here.  One could issue a warning message, but then ignore the unknown component.

In both cases (and I suspect numerous others), halting parsing is an extreme response to various errors, since it leaves the user of the package with no way to process a nonconforming file.  That's especially problematic since VCALENDAR files are generated by so many different programs, many of which are written by programmers who haven't bothered to read RFC 5445--or who have read it but then made some minor mistake that produces broken files.

----------
messages: 304944
nosy: gkuenning
priority: normal
severity: normal
status: open
title: datetime violates Postel's law

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________

From report at bugs.python.org  Tue Oct 24 18:57:02 2017
From: report at bugs.python.org (Geoff Kuenning)
Date: Tue, 24 Oct 2017 22:57:02 +0000
Subject: [issue31864] datetime violates Postel's law
In-Reply-To: <1508885774.85.0.213398074469.issue31864@psf.upfronthosting.co.za>
Message-ID: <1508885822.0.0.213398074469.issue31864@psf.upfronthosting.co.za>


Change by Geoff Kuenning <geoff at cs.hmc.edu>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:03:05 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Oct 2017 23:03:05 +0000
Subject: [issue31864] datetime violates Postel's law
In-Reply-To: <1508885774.85.0.213398074469.issue31864@psf.upfronthosting.co.za>
Message-ID: <1508886185.28.0.213398074469.issue31864@psf.upfronthosting.co.za>


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

The python standard library does not parse files, nor does it have a _parse_rfc message. You say you reported the problem you are having to "the program's maintainer", and that is appropriate.  There does not appear to be anything in this report related to the python standard library, which is what would be appropriate for this bug tracker.

----------
nosy: +r.david.murray
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:04:02 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Oct 2017 23:04:02 +0000
Subject: [issue31864] datetime violates Postel's law
In-Reply-To: <1508885774.85.0.213398074469.issue31864@psf.upfronthosting.co.za>
Message-ID: <1508886242.73.0.213398074469.issue31864@psf.upfronthosting.co.za>


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

I meant the python standard library datetime package doesn't parse files, of course :)  Other parts of the stdlib certainly do parse files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:22:53 2017
From: report at bugs.python.org (Geoff Kuenning)
Date: Tue, 24 Oct 2017 23:22:53 +0000
Subject: [issue31864] datetime violates Postel's law
In-Reply-To: <1508885774.85.0.213398074469.issue31864@psf.upfronthosting.co.za>
Message-ID: <1508887373.69.0.213398074469.issue31864@psf.upfronthosting.co.za>


Geoff Kuenning <geoff at cs.hmc.edu> added the comment:

Duh, my mistake.  The problem is in dateutil, which AFAICT is indeed not part of the Python standard library.  I'll hang my head in shame and go report the problem in the right place.

----------
resolution: third party -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:23:34 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Oct 2017 23:23:34 +0000
Subject: [issue31864] datetime violates Postel's law
In-Reply-To: <1508885774.85.0.213398074469.issue31864@psf.upfronthosting.co.za>
Message-ID: <1508887414.13.0.213398074469.issue31864@psf.upfronthosting.co.za>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31864>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:31:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 23:31:55 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508887915.05.0.213398074469.issue31803@psf.upfronthosting.co.za>


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

Marc-Andre: "Yes, to avoid yet another Python 2/3 difference. It should be replaced with the appropriate variant on Windows and non-Windows platforms. From Serhiy's response that's time.process_time() on non-Windows platforms and time.perf_counter() on Windows."

I don't understand why you mean by "replaced with". Do you mean modify the implementation of the time.clock()?

I would like to kill time.clock() beceause it behaves differently on Windows and non-Windows platforms. There are two choices:

* deprecate time.clock() and later remove time.clock() -- it's deprecated since Python 3.3, and Python 3.7 now emits a DeprecationWarning
* modify time.clock() to get the same behaviour on all platforms: I proposed to modify time.clock() to become a simple alias to time.perf_counter()

Now I'm confused. I'm not sure that I understood what you suggest.

Note: time.clock() already behaves like time.perf_counter() on Windows and time.process_time() on non-Windows. It's exactly how it's implemented. But I consider that it's a bug, and I want to fix it.


"The documentation can point to the new functions and recommend
these over time.clock()."

It's already done in the doc since Python 3.3, no?

https://docs.python.org/dev/library/time.html#time.clock

"Deprecated since version 3.3: The behaviour of this function depends on the platform: use perf_counter() or process_time() instead, depending on your requirements, to have a well defined behaviour."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:37:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 23:37:54 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1508888274.46.0.213398074469.issue31664@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Failure on s390x SLES 3.x:

http://buildbot.python.org/all/#/builders/16/builds/65

======================================================================
FAIL: test_invalid_log_rounds (test.test_crypt.CryptTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-sles-z/build/Lib/test/test_crypt.py", line 60, in test_invalid_log_rounds
    self.assertIsNone(crypt.crypt('mypassword', salt))
AssertionError: '*0' is not None

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:44:49 2017
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 24 Oct 2017 23:44:49 +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: <1508888689.31.0.213398074469.issue15873@psf.upfronthosting.co.za>


Elvis Pranskevichus <elvis at magic.io> added the comment:

I think that both the pyiso8601 and boxed/iso8601 implementations parse ISO 8601 strings incorrectly.  The standard explicitly says that all truncated datetime strings are *reduced accuracy timestamps*.  In other words, "2017-10" is *not* equal to "2017-10-01".  Instead, "2017-10" represents the whole month of October 2017.  Same thing with hours.  Earlier versions of ISO 8601 even allowed dropping the year: "--10-01", which meant October 1st of _any year_.  They dropped this from more recent revisions of the standard.

The only place where the truncated representation means "default to zero" is the timezone offset, so "10:10:00+4" and "10:10:00+04:00" mean the same thing.

----------
nosy: +Elvis.Pranskevichus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Tue Oct 24 19:53:35 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Oct 2017 23:53:35 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508889215.28.0.213398074469.issue30768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 850a18e03e8f8309bc8c39adc6e7d51a4568cd9a by Victor Stinner in branch 'master':
bpo-30768: Recompute timeout on interrupted lock (GH-4103)
https://github.com/python/cpython/commit/850a18e03e8f8309bc8c39adc6e7d51a4568cd9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 20:13:03 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 00:13:03 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508890383.94.0.213398074469.issue30768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I merged my PR. Thanks Antoine Pitrou for the review!

This change only impacts the io.BufferedWriter and io.BufferedReader during Python finalization. It has no effect on theading.Lock.acquire(). It might impact faulthandler.dump_traceback_later(), but in practice, it shouldn't change anything since the internal faulthandler watchdog thread blocks all signals.

If I understand correctly, if the system clock is stepped back by 1 hour during Python finalization, after PyThread_acquire_lock_timed() computed the deadline, but before sem_timedwait() completed, _enter_buffered_busy() can be blocked during 1 hour.

Moving the system clock backward by 1 hour occurs once a year on the DST change. But the race condition is unlikely since the size of the time window is only 1 second. The DST change should occur at Python shutdown when an io.BufferedReader or io.BufferedWriter is used.

Since the race condition seems very unlikely and was never reported by another user, I propose to not backward this change. Moreover, I'm not confident to modify locks in a stable release :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 20:13:12 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 00:13:12 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508890392.83.0.213398074469.issue30768@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 20:15:14 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 00:15:14 +0000
Subject: [issue30768] PyThread_acquire_lock_timed() should recompute the
 timeout when interrupted by a signal
In-Reply-To: <1498485001.71.0.115721395457.issue30768@psf.upfronthosting.co.za>
Message-ID: <1508890514.93.0.213398074469.issue30768@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh, the pthread condvar+mutex implementation still has the bug, so I reopen the issue.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30768>
_______________________________________

From report at bugs.python.org  Tue Oct 24 21:58:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 01:58:48 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508896728.37.0.213398074469.issue21720@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

issue21720_python3.diff hasn't been applied. I'll convert my issue21720_python3.diff patch to a pull request. I like the format of Nick's "".join() example in msg278794. Here's my proposal for Python 3:

    f"Item {i} in 'from list' must be str, not {type(x).__name__!r}"

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Tue Oct 24 22:11:34 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Oct 2017 02:11:34 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508897494.02.0.213398074469.issue31845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset d7ac06126db86f76ba92cbca4cb702852a321f78 by Nick Coghlan in branch 'master':
bpo-31845: Fix reading flags from environment (GH-4105)
https://github.com/python/cpython/commit/d7ac06126db86f76ba92cbca4cb702852a321f78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Tue Oct 24 22:14:21 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Oct 2017 02:14:21 +0000
Subject: [issue31845] PYTHONDONTWRITEBYTECODE and PYTHONOPTIMIZE have no effect
In-Reply-To: <1508757930.52.0.213398074469.issue31845@psf.upfronthosting.co.za>
Message-ID: <1508897661.82.0.213398074469.issue31845@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We could still use some more comprehensive test cases for the env var handling and the way that interacts with the command line settings, but the merged PR includes at least a rudimentary check for the four that directly affect sys.flags without any tricky side effects (PYTHONDEBUG, PYTHONVERBOSE, PYTHONOPTIMIZE, PYTHONDONTWRITEBYTECODE).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31845>
_______________________________________

From report at bugs.python.org  Tue Oct 24 22:46:46 2017
From: report at bugs.python.org (Jun Hui Lee)
Date: Wed, 25 Oct 2017 02:46:46 +0000
Subject: [issue31865] html.unescape does not work as per documentation
Message-ID: <1508899606.23.0.213398074469.issue31865@psf.upfronthosting.co.za>


New submission from Jun Hui Lee <cardinleejh at gmail.com>:

html.unescape(s)
Convert all named and numeric character references (e.g. &gt;, &#62;, &x3e;)

But running this gives:
>>> html.unescape('&gt;, &#62;, &x3e;')
'>, >, &x3e;'

----------
assignee: docs at python
components: Documentation
messages: 304957
nosy: Jun Hui Lee, docs at python
priority: normal
severity: normal
status: open
title: html.unescape does not work as per documentation
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31865>
_______________________________________

From report at bugs.python.org  Tue Oct 24 22:48:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 02:48:48 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508899728.47.0.213398074469.issue21720@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +4083
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Tue Oct 24 23:21:17 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 03:21:17 +0000
Subject: =?utf-8?q?=5Bissue30762=5D_Misleading_message_=E2=80=9Ccan=27t_concat_byt?=
 =?utf-8?b?ZXMgdG8gc3Ry4oCd?=
In-Reply-To: <1498472017.09.0.210411923746.issue30762@psf.upfronthosting.co.za>
Message-ID: <1508901677.3.0.213398074469.issue30762@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30762>
_______________________________________

From report at bugs.python.org  Tue Oct 24 23:22:13 2017
From: report at bugs.python.org (Antoine Pietri)
Date: Wed, 25 Oct 2017 03:22:13 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1508901733.17.0.213398074469.issue29116@psf.upfronthosting.co.za>


Change by Antoine Pietri <antoine.pietri1 at gmail.com>:


----------
keywords: +patch
pull_requests: +4084
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Tue Oct 24 23:33:22 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 Oct 2017 03:33:22 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1508902402.8.0.213398074469.issue29116@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

In the future, I don't think this sort of thing should be backported.  It isn't a bug, rather, it is a "thing x doesn't exactly look like thing y".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Tue Oct 24 23:54:14 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 03:54:14 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1508903654.4.0.213398074469.issue29116@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests:  -4084

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Wed Oct 25 01:36:39 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 Oct 2017 05:36:39 +0000
Subject: [issue27987] obmalloc's 8-byte alignment causes undefined behavior
In-Reply-To: <1473207430.19.0.578630759123.issue27987@psf.upfronthosting.co.za>
Message-ID: <1508909799.19.0.213398074469.issue27987@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Yes, we could memcpy things around to obtain the desired alignment. It would be nicer to have a builtin solution, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27987>
_______________________________________

From report at bugs.python.org  Wed Oct 25 01:41:11 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 05:41:11 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508910070.99.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I don't think the index in error message is needed. Unlike to str.join() which accepts arbitrary iterables of arbitrary names, the fromlist usually is a short tuple.

Interesting, what happen if the fromlist is not a list or tuple?

>>> __import__('encodings', fromlist=iter(('aliases', b'codecs')))
<module 'encodings' from '/home/serhiy/py/cpython/Lib/encodings/__init__.py'>

Import is successful because the iterator was exhausted by "'*' in fromlist".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 01:42:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 05:42:14 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508910134.06.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

>>> __import__('encodings', fromlist=iter(('aliases', b'foobar')))
<module 'encodings' from '/home/serhiy/py/cpython/Lib/encodings/__init__.py'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 02:00:47 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 Oct 2017 06:00:47 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1508837003.19.0.213398074469.issue23699@psf.upfronthosting.co.za>
Message-ID: <1508911243.1278354.1150166152.2FD2DCE5@webmail.messagingengine.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Tue, Oct 24, 2017, at 02:23, Petr Viktorin wrote:
> 
> Petr Viktorin <encukou at gmail.com> added the comment:
> 
> Both tp_richcompare and PyObject_RichCompareBool have op as the last
> argument:

Yes, indeed. Sorry, I wasn't thinking straight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Oct 25 02:20:23 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 Oct 2017 06:20:23 +0000
Subject: [issue31866] clean out some more AtheOS code
Message-ID: <1508912423.08.0.213398074469.issue31866@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

We stopped support AtheOS in 2007. But, there are still references in the code:

$ git grep -i AtheOS
Doc/whatsnew/2.3.rst:Other new platforms now supported by Python include AtheOS
Doc/whatsnew/2.3.rst:(http://atheos.cx/), GNU/Hurd, and OpenVMS.
Lib/distutils/command/build_ext.py:        # for extensions under Cygwin and AtheOS Python's library directory must be
Lib/distutils/command/build_ext.py:        if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos':
Lib/distutils/command/build_ext.py:        elif sys.platform[:6] == "atheos":
Lib/test/test_os.py:            # On AtheOS, glibc always returns ENOSYS
Lib/test/test_os.py:            # On AtheOS, glibc always returns ENOSYS
Misc/HISTORY:- Support for AtheOS has been completely removed from the code base. It was
Misc/HISTORY:- Support for BeOS and AtheOS was removed (according to PEP 11).
Misc/HISTORY:- AtheOS is now supported.
Modules/_cryptmodule.c:    /* On some platforms (AtheOS) crypt returns NULL for an invalid
config.guess:    i*86:atheos:*:*)
config.guess:   echo ${UNAME_MACHINE}-unknown-atheos
config.sub:     -atheos*)
config.sub:             os=-atheos
configure:atheos*|Linux*/1*)
configure.ac:atheos*|Linux*/1*)

----------
messages: 304963
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: clean out some more AtheOS code
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31866>
_______________________________________

From report at bugs.python.org  Wed Oct 25 02:22:15 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 25 Oct 2017 06:22:15 +0000
Subject: [issue31866] clean out some more AtheOS code
In-Reply-To: <1508912423.08.0.213398074469.issue31866@psf.upfronthosting.co.za>
Message-ID: <1508912535.91.0.213398074469.issue31866@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
keywords: +patch
pull_requests: +4085
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31866>
_______________________________________

From report at bugs.python.org  Wed Oct 25 03:01:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 07:01:02 +0000
Subject: [issue31866] clean out some more AtheOS code
In-Reply-To: <1508912423.08.0.213398074469.issue31866@psf.upfronthosting.co.za>
Message-ID: <1508914862.42.0.213398074469.issue31866@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about configure.ac?

"On some platforms (AtheOS)" in the comment in Modules/_cryptmodule.c is redundant. crypt() should return NULL on error, and it often returns NULL for an invalid salt.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31866>
_______________________________________

From report at bugs.python.org  Wed Oct 25 03:23:29 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Oct 2017 07:23:29 +0000
Subject: [issue28503] [Patch] '_crypt' module: fix implicit declaration of
 crypt(), use crypt_r() where available
In-Reply-To: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za>
Message-ID: <1508916209.15.0.213398074469.issue28503@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure performance matters.  Modern crypt() algorithms should actually be slow enough (using a large number of rounds) to make brute-force attacks impractical...

----------
nosy: +pitrou
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28503>
_______________________________________

From report at bugs.python.org  Wed Oct 25 04:07:23 2017
From: report at bugs.python.org (Ed Schouten)
Date: Wed, 25 Oct 2017 08:07:23 +0000
Subject: [issue28503] [Patch] '_crypt' module: fix implicit declaration of
 crypt(), use crypt_r() where available
In-Reply-To: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za>
Message-ID: <1508918843.03.0.213398074469.issue28503@psf.upfronthosting.co.za>


Ed Schouten <ed at nuxi.nl> added the comment:

Having looked at various implementations of crypt() and crypt_r(), I can't think of a reason why there would be any significant difference in performance. On systems like FreeBSD, crypt() is just a simple wrapper around crypt_r():

https://svnweb.freebsd.org/base/head/lib/libcrypt/crypt.c?view=markup#l134

If there would be any difference in performance, it would also be astronomically small compared to the computation time spent by the cryptographic hash functions themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28503>
_______________________________________

From report at bugs.python.org  Wed Oct 25 04:34:23 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 08:34:23 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508920463.48.0.213398074469.issue21720@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> I don't think the index in error message is needed.

I'm fine with either format. It's ultimately up to Nick. Should I switch back to the 2.7 version?

> Import is successful because the iterator was exhausted by "'*' in fromlist".

This shouldn't be a problem in the latest version of PR 4113. While I don't think anyone would pass ``fromlist=iter(('aliases', b'foobar'))`` in real life, I can add it to the test. Let me know what do you think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 04:59:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 08:59:24 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1508921964.91.0.213398074469.issue30855@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Too bad, the bug is not dead:

http://buildbot.python.org/all/#/builders/45/builds/14

test_use (test_tkinter.test_widgets.ToplevelTest) ... ERROR
test_visual (test_tkinter.test_widgets.ToplevelTest) ... ok
test test_tk failed -- Traceback (most recent call last):
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\test\test_tkinter\test_widgets.py", line 92, in test_use
    widget2 = self.create(use=wid)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\test\test_tkinter\test_widgets.py", line 67, in create
    return tkinter.Toplevel(self.root, **kwargs)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\Tkinter.py", line 2138, in __init__
    BaseWidget.__init__(self, master, 'toplevel', cnf, {}, extra)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\Tkinter.py", line 2095, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
TclError: expected integer but got "0x8e5c00d6L"
test_width (test_tkinter.test_widgets.ToplevelTest) ... ok
======================================================================
ERROR: test_use (test_tkinter.test_widgets.ToplevelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\test\test_tkinter\test_widgets.py", line 92, in test_use
    widget2 = self.create(use=wid)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\test\test_tkinter\test_widgets.py", line 67, in create
    return tkinter.Toplevel(self.root, **kwargs)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\Tkinter.py", line 2138, in __init__
    BaseWidget.__init__(self, master, 'toplevel', cnf, {}, extra)
  File "d:\cygwin\home\db3l\buildarea\2.7.bolen-windows\build\lib\lib-tk\Tkinter.py", line 2095, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
TclError: expected integer but got "0x8e5c00d6L"

----------
nosy: +terry.reedy
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Wed Oct 25 05:04:00 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Oct 2017 09:04:00 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508922240.03.0.213398074469.issue21720@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm fine with the approach in the latest version of the PR - it does make "from x import y" slightly slower due to the extra error checking, but folks should be avoiding doing that in performance critical loops or functions anyway.

It would be nice if we could avoid that overhead for the import statement case, but we can't readily tell the difference between "__import__ called via syntax" and "__import__ called directly", and I don't think this is going to be performance critical enough to be worth introducing that complexity.

The question of how best to handle passing a consumable iterator as the from list would be a separate question, if we decided to do anything about it at all (the current implementation implicitly assumes the input is reiterable, but passing a non-container seems like a harder mistake to make than accidentally passing bytes instead of a string).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 05:23:44 2017
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 25 Oct 2017 09:23:44 +0000
Subject: [issue24564] shutil.copytree fails when copying NFS to NFS
In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za>
Message-ID: <1508923424.05.0.213398074469.issue24564@psf.upfronthosting.co.za>


Albert Zeyer <albzey at googlemail.com> added the comment:

I'm also affected by this, with Python 3.6. My home directory is on a ZFS-backed NFS share.
See here for details:
https://github.com/Linuxbrew/homebrew-core/issues/4799

Basically:
Copying setuptools.egg-info to /u/zeyer/.linuxbrew/lib/python3.6/site-packages/setuptools-36.5.0-py3.6.egg-info
error: [Errno 5] Input/output error: '/u/zeyer/.linuxbrew/lib/python3.6/site-packages/setuptools-36.5.0-py3.6.egg-info/zip-safe'

Note that also by other tools, such as `mv` and `cp`, I get errors about setting `system.nfs4_acl`. But they just seem to ignore that and go on. I think this is the right thing to do here. You can print a warning about that, but then just go on. Maybe esp. just for `system.nfs4_acl`.

----------
nosy: +Albert.Zeyer
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24564>
_______________________________________

From report at bugs.python.org  Wed Oct 25 05:34:07 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 09:34:07 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508924047.04.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The from import already is much slower than simple import:

$ ./python -m timeit 'from encodings import aliases'
500000 loops, best of 5: 475 nsec per loop
$ ./python -m timeit 'import encodings.aliases as aliases'
1000000 loops, best of 5: 289 nsec per loop

The latter executes only C code if the module already is imported, but the former executes Python code. It may be worth to add the C acceleration for this case too.

PR 4113 makes it yet slower:
 
$ ./python -m timeit 'from encodings import aliases'
500000 loops, best of 5: 793 nsec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 05:56:00 2017
From: report at bugs.python.org (Tal Einat)
Date: Wed, 25 Oct 2017 09:56:00 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508925360.32.0.213398074469.issue20180@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

As far as I can tell, with the creation of a separate clinic/itertools.c.h, the typedefs etc. need to be moved to the top of the file so that the #include can come after the typedefs and before the rest of the code which references clinic output. Is this indeed the way to go?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Wed Oct 25 06:14:00 2017
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 25 Oct 2017 10:14:00 +0000
Subject: [issue31867] Duplicated keys,
 but with different values in dictionary literals
Message-ID: <1508926440.94.0.213398074469.issue31867@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

Here
https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L416
and here
https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L526

I have no idea which is the correct value for either, but the code is misleading at best.

----------
components: Library (Lib)
messages: 304973
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Duplicated keys, but with different values in dictionary literals
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31867>
_______________________________________

From report at bugs.python.org  Wed Oct 25 06:16:08 2017
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 25 Oct 2017 10:16:08 +0000
Subject: [issue31867] Duplicated keys,
 but with different values in dictionary literals
In-Reply-To: <1508926440.94.0.213398074469.issue31867@psf.upfronthosting.co.za>
Message-ID: <1508926568.76.0.213398074469.issue31867@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

I hadn't noticed the comments on the lines above saying "Duplicates :(", so I'm obviously not the first to notice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31867>
_______________________________________

From report at bugs.python.org  Wed Oct 25 06:16:39 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 25 Oct 2017 10:16:39 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1508926599.96.0.213398074469.issue31852@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This issue is fixed in the master branch (version 3.7.0 alpha 2). The issue was fixed in this PR:

https://github.com/python/cpython/pull/1669

The cause is that async was not a proper keyword and the parser segfaults when checking for the new token and parsing the newline. In particular, this happens here:

translate_newlines at Parser/tokenizer.c:713
713         buf = PyMem_MALLOC(needed_length);

This is the stack trace:

#0  _PyObject_Alloc (ctx=<optimized out>, elsize=10, nelem=1, use_calloc=0) at Objects/obmalloc.c:806
#1  _PyObject_Malloc (ctx=<optimized out>, nbytes=10) at Objects/obmalloc.c:985
#2  0x0000000000453020 in translate_newlines (tok=0x9187b0, exec_input=0, s=0x7ffff7fa40e0 "async \\\n") at Parser/tokenizer.c:713
#3  tok_nextc (tok=tok at entry=0x9187b0) at Parser/tokenizer.c:943
#4  0x0000000000454948 in tok_get (tok=tok at entry=0x9187b0, p_start=p_start at entry=0x7fffffffdc40, p_end=p_end at entry=0x7fffffffdc50)
    at Parser/tokenizer.c:1382
#5  0x0000000000455749 in PyTokenizer_Get (tok=tok at entry=0x9187b0, p_start=p_start at entry=0x7fffffffdc40, p_end=p_end at entry=0x7fffffffdc50)
    at Parser/tokenizer.c:1902
#6  0x000000000045158d in parsetok (tok=0x9187b0, g=<optimized out>, start=256, err_ret=err_ret at entry=0x7fffffffdce0,
    flags=flags at entry=0x7fffffffdcd0) at Parser/parsetok.c:208
#7  0x0000000000452280 in PyParser_ParseFileObject (fp=<optimized out>, filename=filename at entry=0x7ffff7f1b848, enc=<optimized out>,
    g=<optimized out>, start=<optimized out>, ps1=<optimized out>, ps2=0x7ffff7e63648 "... ", err_ret=err_ret at entry=0x7fffffffdce0,
    flags=flags at entry=0x7fffffffdcd0) at Parser/parsetok.c:134
#8  0x0000000000433949 in PyParser_ASTFromFileObject (fp=<optimized out>, filename=0x7ffff7f1b848, enc=<optimized out>,
    start=<optimized out>, ps1=<optimized out>, ps2=<optimized out>, flags=0x7fffffffde90, errcode=0x7fffffffdd80, arena=0x7ffff7fe2168)
    at Python/pythonrun.c:1166
#9  0x0000000000433b5b in PyRun_InteractiveOneObject (fp=fp at entry=0x7ffff74b2640 <_IO_2_1_stdin_>, filename=filename at entry=0x7ffff7f1b848,
    flags=flags at entry=0x7fffffffde90) at Python/pythonrun.c:218
#10 0x0000000000433eae in PyRun_InteractiveLoopFlags (fp=fp at entry=0x7ffff74b2640 <_IO_2_1_stdin_>,
    filename_str=filename_str at entry=0x5dd7a4 "<stdin>", flags=flags at entry=0x7fffffffde90) at Python/pythonrun.c:115
#11 0x0000000000433fbc in PyRun_AnyFileExFlags (fp=0x7ffff74b2640 <_IO_2_1_stdin_>, filename=0x5dd7a4 "<stdin>", closeit=0,
    flags=0x7fffffffde90) at Python/pythonrun.c:77
#12 0x00000000004476fa in run_file (p_cf=0x7fffffffde90, filename=<optimized out>, fp=0x7ffff74b2640 <_IO_2_1_stdin_>) at Modules/main.c:341
#13 Py_Main (argc=argc at entry=1, argv=argv at entry=0x910010) at Modules/main.c:895
#14 0x000000000041e17a in main (argc=1, argv=<optimized out>) at ./Programs/python.c:102

After applying commit ac317700ce7439e38a8b420218d9a5035bba92ed the issue is fixed.

Does it make sense to backport ac317700ce7439e38a8b420218d9a5035bba92ed to 3.6?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Wed Oct 25 06:22:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 10:22:33 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508926953.87.0.213398074469.issue20180@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is. Actually the #include should be before lists of methods and static PyTypeObject initializers. I think it is better to move all method lists and type initializers to the bottom of the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Wed Oct 25 06:25:18 2017
From: report at bugs.python.org (=?utf-8?q?Tomasz_Mi=C4=85sko?=)
Date: Wed, 25 Oct 2017 10:25:18 +0000
Subject: [issue31868] Null pointer dereference in ndb.ndbm get when used with
 a default value.
Message-ID: <1508927118.96.0.213398074469.issue31868@psf.upfronthosting.co.za>


New submission from Tomasz Mi?sko <tomasz.miasko at gmail.com>:

Using ndb.ndbm get when key is missing and default value has to be returned
results in invocation of Py_INCREF on null pointer. Test case to reproduce the issue:

```
import dbm.ndbm

with dbm.ndbm.open('db', 'n') as db:
    print(db.get('missing-key'))
```

----------
files: 0001-Fix-null-pointer-dereference-in-dbm.ndbm-get.patch
keywords: patch
messages: 304977
nosy: tmiasko
priority: normal
severity: normal
status: open
title: Null pointer dereference in ndb.ndbm get when used with a default value.
type: crash
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47236/0001-Fix-null-pointer-dereference-in-dbm.ndbm-get.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31868>
_______________________________________

From report at bugs.python.org  Wed Oct 25 07:42:44 2017
From: report at bugs.python.org (Andy)
Date: Wed, 25 Oct 2017 11:42:44 +0000
Subject: [issue31809] ssl module unnecessarily pins the client curve when
 using ECDH
In-Reply-To: <1508332540.28.0.213398074469.issue31809@psf.upfronthosting.co.za>
Message-ID: <1508931764.3.0.213398074469.issue31809@psf.upfronthosting.co.za>


Andy <grrrrrrrrr at surfsup.at> added the comment:

Thanks for adding the test!

If the official stance is that only the latest OpenSSL is supported then this is definitely WAI. Sounds like a good policy...

I'll close this issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31809>
_______________________________________

From report at bugs.python.org  Wed Oct 25 07:56:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 11:56:33 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1508932593.16.0.213398074469.issue31664@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4086
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Wed Oct 25 07:57:12 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Wed, 25 Oct 2017 11:57:12 +0000
Subject: [issue31867] Duplicated keys in MIME type_map with different values
In-Reply-To: <1508926440.94.0.213398074469.issue31867@psf.upfronthosting.co.za>
Message-ID: <1508932632.36.0.213398074469.issue31867@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

So for excel, 'application/excel' is not listed at http://www.iana.org/assignments/media-types as suggested by the comment at:
https://github.com/python/cpython/blob/master/Lib/mimetypes.py#L397
whereas 'applicaton/vnd.ms-excel' is listed. See also
https://stackoverflow.com/questions/974079/setting-mime-type-for-excel-document.

For cdf, Wolframalpha is using application/cdf it seems (without it being registered) whereas NetCDF suggests application/x-netcdf so that seems reasonable (and is the current value).

For context, these duplicates were introduced here:
https://github.com/python/cpython/commit/a3689fe78675c89d5979c0c5acdb1c173cc75ed6
and noted first here:
https://github.com/python/cpython/commit/107771a228ee73b4683242cb696e3024f93b74d5

----------
nosy: +Henk-Jaap Wagenaar
title: Duplicated keys, but with different values in dictionary literals -> Duplicated keys in MIME type_map with different values

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31867>
_______________________________________

From report at bugs.python.org  Wed Oct 25 07:58:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 11:58:41 +0000
Subject: [issue31868] Null pointer dereference in ndb.ndbm get when used with
 a default value.
In-Reply-To: <1508927118.96.0.213398074469.issue31868@psf.upfronthosting.co.za>
Message-ID: <1508932721.29.0.213398074469.issue31868@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Could you please create a pull request on GitHub Tomasz?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31868>
_______________________________________

From report at bugs.python.org  Wed Oct 25 08:15:31 2017
From: report at bugs.python.org (Tal Einat)
Date: Wed, 25 Oct 2017 12:15:31 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508933731.91.0.213398074469.issue20180@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +4087
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Wed Oct 25 08:17:09 2017
From: report at bugs.python.org (Tal Einat)
Date: Wed, 25 Oct 2017 12:17:09 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1508933829.85.0.213398074469.issue20180@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

See PR 4117 on GitHub with the itertools AC conversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Wed Oct 25 08:26:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 12:26:19 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508934379.89.0.213398074469.issue31835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 086c3ae5f0995a62092b9080f32dd118c2923453 by Victor Stinner in branch 'master':
bpo-31835: Optimize also FASTCALL using __future__ (#4087)
https://github.com/python/cpython/commit/086c3ae5f0995a62092b9080f32dd118c2923453


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 08:27:17 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 12:27:17 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508934437.58.0.213398074469.issue31835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Thank you Anselm Kruis for spotting this nice optimization opportunity! Sadly, as I wrote, I don't want to backport the optimization to the stable Python 3.6 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 08:27:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 12:27:25 +0000
Subject: [issue31835] _PyFunction_FastCallDict and
 _PyFunction_FastCallKeywords: fast path not used
In-Reply-To: <1508584444.52.0.213398074469.issue31835@psf.upfronthosting.co.za>
Message-ID: <1508934445.72.0.213398074469.issue31835@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 08:54:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 12:54:17 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508936057.36.0.213398074469.issue21720@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4088

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 09:04:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 13:04:37 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508936677.07.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There are other differences between Python 2.7 and Python 3. PR 4118 restores the Python 2.7 logic. It adds type checking, but its overhead is smaller.

$ ./python -m timeit 'from encodings import aliases'
500000 loops, best of 5: 542 nsec per loop

Actually in some cases (with '*') the new code is even slightly faster.

I don't know whether these differences were intentional, but all tests are passed.

The type of items in __all__ also is checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 09:30:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 13:30:19 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1508938219.12.0.213398074469.issue31664@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0f261583bae7e60e410709ed96398dd1b14c5454 by Serhiy Storchaka in branch 'master':
bpo-31664: Fix test_crypt for the openwall implementation of crypt. (#4116)
https://github.com/python/cpython/commit/0f261583bae7e60e410709ed96398dd1b14c5454


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Wed Oct 25 09:47:43 2017
From: report at bugs.python.org (Tal Einat)
Date: Wed, 25 Oct 2017 13:47:43 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508939263.46.0.213398074469.issue21720@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I can't say I agree that the performance here is practically insignificant. This will affect the startup time of Python process, and adding even 10% to that in some cases is significant.

In some of the larger codebases I've worked on, even simple scripts would import large portions of the system, and there would be thousands of such imports done in the process. There are "basic" utilities in the stdlib which are imported very often in different modules, so the performance of the import statement is not necessarily insignificant compared to that of actually loading the modules.

That being said I'm all for getting this in and implementing an optimization of the slower path in time for 3.7.

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 09:55:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 13:55:11 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508939711.92.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Using nested _PyMem_DebugRawRealloc() looks suspicions to me. This may be a bug.

PyObject_Malloc() calls PyMem_RawMalloc() for allocations larger than 512 bytes.

When debug hooks are enabled, PyObject_Malloc() and PyMem_RawMalloc() both call _PyMem_DebugRawRealloc(). The behaviour that you saw is expected.

It was simpler to reuse _PyMem_DebugRawRealloc() PyObject and PyMem_Raw allocator families, rather than duplicating the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 10:15:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 14:15:59 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508940959.57.0.213398074469.issue31626@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 10:18:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 14:18:51 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508941131.5.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"I tried to build CPython on 64-bit OpenBSD. It was built successfully, but tests crash."

It's the first time that anyone complains about _PyMem_DebugRawRealloc(). The behaviour seems to be very specific to OpenBSD.

Even if the current code is "weird", it works very well and is effecient.

I proposed attached PR 4119 which makes _PyMem_DebugRawRealloc() behaves correctly: erase bytes *before* calling realloc(), but keeps a copy if realloc() fails. My PR only changes the behaviour on OpenBSD. It keeps the current behaviour (erase bytes *after* realloc, if realloc succeeded) on other platforms for performance reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 10:33:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 14:33:21 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508942001.5.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Currently, the main question on my PR 4089 was raised by Antoine Pitrou:
"Do people have to provide aligned_alloc and aligned_free? Or can they leave those pointers NULL and get a default implementation?"

My reply: "Currently, you must provide all allocator functions, included aligned_alloc and aligned_free. Technically, we can implement a fallback, but I'm not sure that I want to do that :-)"

I'm not sure about that. I can imagine platforms which provide a special malloc/free and that's all: no calloc, posix_memalign or _aligned_malloc(). But is Python suppose to fills the holes? For example, implement calloc() as malloc()+memset()? Or is the user of the PyMem_SetAllocator() API responsible to reimplement them?

In Python 3.5, we added the requirement of a working calloc().

In Python 3.7, should we also add the "aligned alloc" requirement?

In case of doubt, I prefer not to guess, and leave the decision to the caller of the API: require all functions to be implemented.

I'm not sure that it's a good idea to provide a "aligned malloc" fallback if such fallback would be inefficient. For example, we would have to overallocate the memory block not only for the requested alignement, but also allocates extra sizeof(size_t) bytes, *in each* aligned memmory block, to store the size of the alignment itself, to recover the original pointer... to finally be able to call free().

An aligned memory block would look like: [AAAAA SSS DDD...DDDDDDD] where AAAAA are bytes lost for alignment, SSS bytes storing the alignment size (size of "AAAAA" in this example), and "DDD...DDDDDDD" would be the actual data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 10:41:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 14:41:00 +0000
Subject: [issue31664] Add support of new crypt methods
In-Reply-To: <1506936288.65.0.213398074469.issue31664@psf.upfronthosting.co.za>
Message-ID: <1508942460.48.0.213398074469.issue31664@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tests on s390x SLES 3.x are passed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31664>
_______________________________________

From report at bugs.python.org  Wed Oct 25 10:55:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 14:55:08 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508943308.77.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The current code in not correct on all platforms. We don't know how many of random bugs, hangs and crashes on other platforms are caused by this bug. I'm not surprised that it was caught on OpenBSD since the robustness and security of software is the goal of OpenBSD.

PR 3844 restores the behavior of 2.7 and 3.3. I propose to merge it first, and develop other enhancements later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 11:00:21 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 15:00:21 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508943621.59.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> PR 3844 restores the behavior of 2.7 and 3.3. I propose to merge it first, and develop other enhancements later.

Please don't. This PR reintroduced a bug that I fixed in bpo-18408:

commit c4266360fc70745d49b09f2c29cda91c1a007525
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Tue Jul 9 00:44:43 2013 +0200

    Issue #18408: Fix _PyMem_DebugRealloc()
    
    Don't mark old extra memory dead before calling realloc(). realloc() can fail
    and realloc() must not touch the original buffer on failure.
    
    So mark old extra memory dead only on success if the new buffer did not move
    (has the same address).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 11:02:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 15:02:58 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508943778.01.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> The current code in not correct on all platforms.

My PR 4119 only changes the behaviour on OpenBSD, but I'm not sure about that. Maybe it's simpler to apply this fix on all platforms, as I asked on the PR itself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 11:36:07 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 25 Oct 2017 15:36:07 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508945767.46.0.213398074469.issue25083@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

tzickel, could you sign the CLA? It will formally allow PSF to distribute your patch with Python. (You retain the copyright.) See the dev guide for instructions: https://docs.python.org/devguide/pullrequest.html#cla

I can't do that for you, but if you want, I can do the rest (open a pull request and convince some core developer to merge it) after you sign the CLA.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Wed Oct 25 11:49:20 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 15:49:20 +0000
Subject: [issue25083] Python can sometimes create incorrect .pyc files
In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
Message-ID: <1508946560.47.0.213398074469.issue25083@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25083>
_______________________________________

From report at bugs.python.org  Wed Oct 25 11:49:50 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 15:49:50 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1508946590.64.0.213398074469.issue31852@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Wed Oct 25 11:56:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Oct 2017 15:56:06 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1508946966.69.0.213398074469.issue31852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Does it make sense to backport ac317700ce7439e38a8b420218d9a5035bba92ed to 3.6?

No, async was not a keyword in Python 3.6 on purpose. Making it a keyword can break a lot of code.

I confirm that Python 3.6 still crashs with a very high number of "async " prefixes: try attached async_parser_crash.py.

Extract of the gdb traceback on a crash:

(...)
#665 0x0000000000454867 in tok_get (tok=0x7fffff8b98c0, 
    p_start=0x7fffff8b9cb8, p_end=0x7fffff8b9cb0) at Parser/tokenizer.c:1571
#666 0x0000000000454867 in tok_get (tok=0x7fffff8b9d40, 
    p_start=0x7fffff8ba138, p_end=0x7fffff8ba130) at Parser/tokenizer.c:1571
#667 0x0000000000454867 in tok_get (tok=0x7fffff8ba1c0, 
    p_start=0x7fffff8ba5b8, p_end=0x7fffff8ba5b0) at Parser/tokenizer.c:1571
#668 0x0000000000454867 in tok_get (tok=0x7fffff8ba640, 
    p_start=0x7fffff8baa38, p_end=0x7fffff8baa30) at Parser/tokenizer.c:1571
#669 0x0000000000454867 in tok_get (tok=0x7fffff8baac0, 
    p_start=0x7fffff8baeb8, p_end=0x7fffff8baeb0) at Parser/tokenizer.c:1571
#670 0x0000000000454867 in tok_get (tok=0x7fffff8baf40, 
    p_start=0x7fffff8bb338, p_end=0x7fffff8bb330) at Parser/tokenizer.c:1571
#671 0x0000000000454867 in tok_get (tok=0x7fffff8bb3c0, 
    p_start=0x7fffff8bb7b8, p_end=0x7fffff8bb7b0) at Parser/tokenizer.c:1571
(...)

It looks like a stack overflow.

The tokenizer may fail earlier on "async async ".

----------
nosy: +haypo
Added file: https://bugs.python.org/file47237/async_parser_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:01:35 2017
From: report at bugs.python.org (J Sloot)
Date: Wed, 25 Oct 2017 16:01:35 +0000
Subject: [issue31869] commentary on ssl.PROTOCOL_TLS
Message-ID: <1508947295.4.0.213398074469.issue31869@psf.upfronthosting.co.za>


New submission from J Sloot <jsloot at gmail.com>:

on https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS
for ssl.PROTOCOL_TLS

When the commentary from ssl.PRTOCOL_TLS moved from PROTOCOL_SSLv23 to PROTOCOL_TLS the note {Despite the name, this option can select "TLS" protocols as well as "SSL"} didn't change.

Suggested new wording {Despite the name, this option can select "SSL" protocols as well as "TLS"}

----------
assignee: docs at python
components: Documentation
messages: 304996
nosy: J Sloot, docs at python
priority: normal
severity: normal
status: open
title: commentary on ssl.PROTOCOL_TLS
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31869>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:09:05 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Oct 2017 16:09:05 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508887915.05.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <2ee498bb-937f-89a4-d4e0-d9a004093eb0@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 25.10.2017 01:31, STINNER Victor wrote:
> 
> Marc-Andre: "Yes, to avoid yet another Python 2/3 difference. It should be replaced with the appropriate variant on Windows and non-Windows platforms. From Serhiy's response that's time.process_time() on non-Windows platforms and time.perf_counter() on Windows."
> 
> I don't understand why you mean by "replaced with". Do you mean modify the implementation of the time.clock()?

What I meant is that time.clock() is replaced with the higher
accuracy timers corresponding to the current time.clock()
implementation on the various platforms in order to retain
backwards compatibility.

In other words:

if sys.platform == 'win32':
    time.clock = time.perf_counter
else:
    time.clock = time.process_time

I know that time.clock() behaves differently on different platforms,
but this fact has been known for a long time and is being used by
Python code out there for timing purposes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:09:22 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 16:09:22 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1508947762.51.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In this case it would be safe to not erase bytes at all.

PR 4119 is too complex for a bugfix (especially if backport it to 3.5 and 3.4). It can introduce other regressions. The performance hit is not the only issue. Allocating a temporary buffer can change the structure of "holes" in memory. As result some memory related bugs can be reproducible only in release mode.

Maybe it is enough to erase only few bytes at the start and end of the freed area. The copy can be saved in local variables, without involving the heap. This solution still will be enough complex, and I think it can be applied only to 3.7. But the bug should be fixed in all affected versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:11:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 16:11:33 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508947893.05.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is the current behavior. Do you suggest to undeprecate time.clock() after 4 releases of deprecation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:25:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 16:25:02 +0000
Subject: [issue28564] shutil.rmtree is inefficient due to listdir() instead of
 scandir()
In-Reply-To: <1477857759.23.0.231777495226.issue28564@psf.upfronthosting.co.za>
Message-ID: <1508948702.56.0.213398074469.issue28564@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Following Antoine's suggestion the patch now makes shutil.rmtree() using os.scandir() on all platforms.

I doubt about one thing. This patch changes os.listdir passed to the onerror handler to os.scandir. This can break a user code that checks if the first argument in onerror is os.listdir. If keep this change, it should be documented in the "Porting to 3.7" section. Alternatively, we can continue passing os.listdir if os.scandir() failed despites the fact that os.listdir no longer used.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28564>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:25:57 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Oct 2017 16:25:57 +0000
Subject: [issue28564] shutil.rmtree is inefficient due to listdir() instead of
 scandir()
In-Reply-To: <1477857759.23.0.231777495226.issue28564@psf.upfronthosting.co.za>
Message-ID: <1508948757.38.0.213398074469.issue28564@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think we should change to os.scandir.  No need to accumulate compatibility baggage like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28564>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:36:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 16:36:47 +0000
Subject: [issue31702] Allow to specify the number of rounds for SHA-* hashing
 in crypt
In-Reply-To: <1507206772.04.0.213398074469.issue31702@psf.upfronthosting.co.za>
Message-ID: <1508949407.86.0.213398074469.issue31702@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What to do with values outside of the valid range (2**4 to 2**31 for Blowfish, 1000 to 999999999 for SHA*). Raise ValueError, OverflowError, or bound it, or just generate an invalid salt and allow crypt() to handle it?

----------
nosy: +haypo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31702>
_______________________________________

From report at bugs.python.org  Wed Oct 25 12:52:32 2017
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Oct 2017 16:52:32 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508950352.76.0.213398074469.issue18835@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

> In Python 3.7, should we also add the "aligned alloc" requirement?

Linux, BSD, OSX, MSVC should be covered. According to Stackoverflow
MinGW has an internal function.

Android, I don't know. Xavier?

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 13:07:15 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 25 Oct 2017 17:07:15 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1508951235.17.0.213398074469.issue31803@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I would like to add my voice to MAL's objections.  I was not aware of time.clock() depreciation before Victor brought this issue to my attention.  time.clock() is a very well-known API eponymous to a venerable UNIX system call.  Its limitations and platform dependencies are very well-known as well.  For someone new to python, seeing time.clock() would probably not require a trip to the library reference, but seeing time.perf_counter() is likely to cause a WTF reaction even from an experienced python developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Wed Oct 25 13:38:10 2017
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 25 Oct 2017 17:38:10 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508953090.8.0.213398074469.issue21720@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

As Nick said, if the overhead of an import statement is that critical, then you should NOT use the `from ... import ...` form at all and just stick with `import ...` and if necessary, bind local names to objects off of the final module or a local name for the overall module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 13:47:36 2017
From: report at bugs.python.org (Tal Einat)
Date: Wed, 25 Oct 2017 17:47:36 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508953656.47.0.213398074469.issue21720@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I understand that there is a workaround. I'm just thinking about the many existing large codebases where re-writing thousands of imports because of this is unlikely to be done, yet having somewhat longer process launch times would be surprising and unwanted.

Anyways I do think it's a very small price to pay for better error messages, and there's a good chance nobody will actually feel the difference, so let's definitely move forward with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 15:28:41 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Oct 2017 19:28:41 +0000
Subject: [issue15335] IDLE - debugger steps into print and over rpc.py code
In-Reply-To: <1342111374.05.0.899363686539.issue15335@psf.upfronthosting.co.za>
Message-ID: <1508959721.51.0.213398074469.issue15335@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The debugger also steps into importlib, if one steps 'into' an import statement.  Most of the time, this is a nuisance.  If one is importing from one's own module, stepping over 'import mymod' is not a satisfactory way to avoid this.  Perhaps we should add '(X) Step past IDLE internals' and '(X) Step past Python internals', both on by default.  'python internals' would be builtin features that happen be implemented, at least in CPython, in python rather than the internal language. Other ideas: a drop down skip list with items checked.  Or a general policy of skipping Lib/* with a list of exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15335>
_______________________________________

From report at bugs.python.org  Wed Oct 25 16:12:23 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Oct 2017 20:12:23 +0000
Subject: [issue17942] IDLE Debugger: Improve GUI
In-Reply-To: <1368076818.55.0.00268388045116.issue17942@psf.upfronthosting.co.za>
Message-ID: <1508962343.04.0.213398074469.issue17942@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE now uses ttk unconditionally by requiring tk 8.5.  The patch can therefore be simplified accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17942>
_______________________________________

From report at bugs.python.org  Wed Oct 25 16:46:55 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 25 Oct 2017 20:46:55 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508964415.51.0.213398074469.issue18835@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Android has both memalign() [1] and posix_memalign() [2] and does not have aligned_alloc(), posix_memalign() is a wrapper around memalign() [3].

[1] https://android.googlesource.com/platform/bionic/+/master/libc/include/malloc.h#38
[2] https://android.googlesource.com/platform/bionic/+/master/libc/include/stdlib.h#80
[3] https://android.googlesource.com/platform/bionic/+/85aad90%5E%21/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 17:11:10 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 21:11:10 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1508965870.52.0.213398074469.issue30855@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4090
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Wed Oct 25 17:12:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 21:12:27 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1508965947.23.0.213398074469.issue30855@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In Python 2 hex() adds the 'L' suffix for longs.

----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Wed Oct 25 17:28:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 21:28:08 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1508966888.14.0.213398074469.issue30855@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7c622be4f2e86c1999baba4f64671a5987d43d73 by Serhiy Storchaka in branch '2.7':
bpo-30855: Fix winfo_id related Tkinter test on Windows. (#4121)
https://github.com/python/cpython/commit/7c622be4f2e86c1999baba4f64671a5987d43d73


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Wed Oct 25 17:38:08 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 25 Oct 2017 21:38:08 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1508967488.28.0.213398074469.issue18835@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> I'm not sure that it's a good idea to provide a "aligned malloc" fallback if such fallback would be inefficient. For example, we would have to overallocate the memory block not only for the requested alignement, but also allocates extra sizeof(size_t) bytes, *in each* aligned memmory block, to store the size of the alignment itself, to recover the original pointer... to finally be able to call free().

You can re-use the same bytes for padding and to store the offset. The main tricky thing is that for an alignment of N bytes you need to overallocate N bytes instead of (N-1). (In the worst case, malloc returns you a pointer that's already N-byte aligned, and then you have to advance it by a full N bytes so that you have some space before the pointer to store the offset.)

Also you want to do a little N = max(N, sizeof(whatever int type you use)) at the beginning to make sure it's always big enough, but this is trivial (and really even a uint16_t is plenty big to store all reasonable alignments). And make sure that N is a power-of-two, which guarantees that whatever value malloc returns will be shifted by at least malloc's regular alignment, which is guaranteed to be large enough to store a standard int type (on reasonable systems).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Wed Oct 25 17:44:01 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Oct 2017 21:44:01 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1499257127.67.0.747001147165.issue30855@psf.upfronthosting.co.za>
Message-ID: <1508967841.08.0.213398074469.issue30855@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Wed Oct 25 18:21:52 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 25 Oct 2017 22:21:52 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1508970112.94.0.213398074469.issue31852@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +4091
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Wed Oct 25 18:46:49 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 25 Oct 2017 22:46:49 +0000
Subject: [issue31702] Allow to specify the number of rounds for SHA-* hashing
 in crypt
In-Reply-To: <1508949407.86.0.213398074469.issue31702@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNJRL3phFRPsYQw_7RAxHXeuY-GAXVjYhQAmOjL7QXtZQA@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

I'd stick with ValueError in that case as well.  if someone dislikes the
valueerrors because they _want_ to use an invalid one, they can file a bug
and we'll reconsider only if they have a meaningful use case.

On Wed, Oct 25, 2017 at 9:36 AM Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> What to do with values outside of the valid range (2**4 to 2**31 for
> Blowfish, 1000 to 999999999 for SHA*). Raise ValueError, OverflowError, or
> bound it, or just generate an invalid salt and allow crypt() to handle it?
>
> ----------
> nosy: +haypo, pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31702>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31702>
_______________________________________

From report at bugs.python.org  Wed Oct 25 18:48:05 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 22:48:05 +0000
Subject: [issue30811] A venv created and activated from within a virtualenv
 uses the outer virtualenv's site-packages rather than its own.
In-Reply-To: <1498813368.34.0.349011380575.issue30811@psf.upfronthosting.co.za>
Message-ID: <1508971685.98.0.213398074469.issue30811@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30811>
_______________________________________

From report at bugs.python.org  Wed Oct 25 19:00:11 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Oct 2017 23:00:11 +0000
Subject: [issue29933] asyncio: set_write_buffer_limits() doc doesn't specify
 unit of the parameters
In-Reply-To: <1490707139.27.0.838851028066.issue29933@psf.upfronthosting.co.za>
Message-ID: <1508972411.42.0.213398074469.issue29933@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

PR 2262 has been merged and backported to bugfix branches so I think this issue can be closed now.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29933>
_______________________________________

From report at bugs.python.org  Wed Oct 25 20:10:21 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 Oct 2017 00:10:21 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1508976621.21.0.213398074469.issue24954@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am going to merge PR 4015 submitted for issue 31800.  That issue asks to make %z strptime format accept offsets with : separators.  Given that a similar feature has been added to glibc several years ago, I don't see much need for bikeshedding.  This issue will remain open and will focus on strftime.

----------
dependencies: +datetime.strptime: Support for parsing offsets with a colon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24954>
_______________________________________

From report at bugs.python.org  Wed Oct 25 20:18:34 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 26 Oct 2017 00:18:34 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1508977114.17.0.213398074469.issue24954@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

SGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24954>
_______________________________________

From report at bugs.python.org  Wed Oct 25 20:35:43 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 Oct 2017 00:35:43 +0000
Subject: [issue31800] datetime.strptime: Support for parsing offsets with a
 colon
In-Reply-To: <1508194309.26.0.213398074469.issue31800@psf.upfronthosting.co.za>
Message-ID: <1508978143.76.0.213398074469.issue31800@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:


New changeset 32318930da70ff03320ec50813b843e7db6fbc2e by Alexander Belopolsky (Mario Corchero) in branch 'master':
Closes bpo-31800: Support for colon when parsing time offsets (#4015)
https://github.com/python/cpython/commit/32318930da70ff03320ec50813b843e7db6fbc2e


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31800>
_______________________________________

From report at bugs.python.org  Wed Oct 25 21:47:12 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Oct 2017 01:47:12 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1508982432.0.0.213398074469.issue24920@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If one starts IDLE from a command-line console (python -m idlelib) or Python console (import idlelib.idle), sys.__stdout__ is the TextIOWraper for that console and .fileno() returns 1.  .get_terminal_size() will then return the console size.  The exception occurs when IDLE is  started from an icon.

Implementing David's suggestion for shutil will be easy: insert just before the fileno call
    if not sys.__stdout__: raise ValueError()
This is what os.get_terminal_size() raises on IDLE.  Comments in the code in posixpath.c make it clear that this is intended guis and the low_level os function.

This came up today on Stackoverflow when someone tried to use matplotlib.pyplot, which calls os.get_terminal_size, on IDLE.
https://stackoverflow.com/questions/46921087/pyplot-with-idle
(Patching shutil will not help for the os call.)

----------
nosy: +terry.reedy
stage:  -> test needed
type: crash -> behavior
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Wed Oct 25 22:49:46 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Oct 2017 02:49:46 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1508986186.52.0.213398074469.issue21720@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Serhiy's PR avoids the cryptic BytesWarning on Py3 while minimising the overhead of the new typecheck, so I've closed Berker's PR in favour of that one (which now has approved reviews from both Brett and I, so Serhiy will merge it when he's ready to do so).

Thanks for both patches!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Wed Oct 25 23:24:56 2017
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 26 Oct 2017 03:24:56 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1508988296.54.0.213398074469.issue31863@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

Setting the exit code to the negative of a C signal value isn't generally meaningful in Windows. It seems multiprocessing doesn't have a significant use for this, other than getting a formatted exit code in the repr via its _exitcode_to_name dict. For example:

    p = multiprocessing.Process(target=time.sleep, args=(30,))
    p.start()
    p.terminate()

    >>> p
    <Process(Process-1, stopped[SIGTERM])>

This may mislead people into thinking incorrectly that Windows implements POSIX signals. Python uses the C runtime's emulation of the basic set of required signals. SIGSEGV, SIGFPE, and SIGILL are based on exceptions. SIGINT and SIGBREAK are based on console control events. SIGABRT and SIGTERM are for use with C `raise`. Additionally it implements os.kill via TerminateProcess and GenerateConsoleCntrlEvent. (The latter takes process group IDs, so it should have been used to implement os.killpg instead. Its use in os.kill is wrong and confusing.)

The normal exit code for a forced shutdown is 1, which you can confirm via Task Manager or `taskkill /F`. subprocess is correct here. I think multiprocessing should follow suit.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Wed Oct 25 23:26:27 2017
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 26 Oct 2017 03:26:27 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1508988387.96.0.213398074469.issue31863@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Thu Oct 26 00:11:27 2017
From: report at bugs.python.org (Vex Woo)
Date: Thu, 26 Oct 2017 04:11:27 +0000
Subject: [issue31870] add timeout parameter for get_server_certificate in
 ssl.py
Message-ID: <1508991085.56.0.213398074469.issue31870@psf.upfronthosting.co.za>


New submission from Vex Woo <hap.ddup at gmail.com>:

The original get_server_certificate in ssl.py does not support socket timeout,

def get_server_certificate(addr, ssl_version=PROTOCOL_TLS, ca_certs=None):
    """Retrieve the certificate from the server at the specified address,
    and return it as a PEM-encoded string.
    If 'ca_certs' is specified, validate the server cert against it.
    If 'ssl_version' is specified, use it in the connection attempt."""

    host, port = addr
    if ca_certs is not None:
        cert_reqs = CERT_REQUIRED
    else:
        cert_reqs = CERT_NONE
    context = _create_stdlib_context(ssl_version,
                                     cert_reqs=cert_reqs,
                                     cafile=ca_certs)
    with  create_connection(addr) as sock:
        with context.wrap_socket(sock) as sslsock:
            dercert = sslsock.getpeercert(True)
    return DER_cert_to_PEM_cert(dercert)

If a timeout parameter, a sample demo can be here:

>>> import ssl
>>> ssl.get_server_certificate(("www.qq.com", 443), timeout=6)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ssl.py", line 1017, in get_server_certificate
    with closing(create_connection(addr, timeout)) as sock:
  File "/usr/lib/python2.7/socket.py", line 575, in create_connection
    raise err
socket.error: [Errno 101] Network is unreachable

----------
components: Library (Lib)
files: ssl.py
messages: 305021
nosy: Nixawk
priority: normal
pull_requests: 4092
severity: normal
status: open
title: add timeout parameter for get_server_certificate in ssl.py
type: enhancement
Added file: https://bugs.python.org/file47238/ssl.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31870>
_______________________________________

From report at bugs.python.org  Thu Oct 26 01:01:52 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 05:01:52 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1508994112.2.0.213398074469.issue20486@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

xoviat, would you like to send your patch as a pull request on GitHub? It would be nice to add a simple test that the new Close() works correctly. I can do that if you don't have time, thank you!

Steve, can we apply this to bugfix branches?

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Thu Oct 26 01:33:13 2017
From: report at bugs.python.org (Mateusz Kurek)
Date: Thu, 26 Oct 2017 05:33:13 +0000
Subject: [issue31871] Support for file descriptor params in os.path
Message-ID: <1508995993.41.0.213398074469.issue31871@psf.upfronthosting.co.za>


New submission from Mateusz Kurek <master.mateusz at gmail.com>:

Since Python 3.3, some os module functions, like os.stat (https://docs.python.org/3/library/os.html#os.stat), support passing file descriptor instead of a path. os.path functions, on the other hand (like os.path.exists - https://docs.python.org/3/library/os.path.html#os.path.exists - or os.path.samefile - https://docs.python.org/3/library/os.path.html#os.path.samefile) mention using os.stat underneath, but according to documentation, does not support passing file descriptor instead of a path (at least it's not mentioned in the docs that this feature is supported). Is this intentional (os.path functions should not take file descriptor params) or this feature is officialy supported, but it's ommited in the docs?

----------
assignee: docs at python
components: Documentation
messages: 305023
nosy: Mateusz Kurek, docs at python
priority: normal
severity: normal
status: open
title: Support for file descriptor params in os.path
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31871>
_______________________________________

From report at bugs.python.org  Thu Oct 26 02:03:07 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Oct 2017 06:03:07 +0000
Subject: [issue31857] Make the behavior of USE_STACKCHECK deterministic
In-Reply-To: <1508807362.1.0.213398074469.issue31857@psf.upfronthosting.co.za>
Message-ID: <1508997787.4.0.213398074469.issue31857@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 1896793520a49a6f97ae360c0b288967e56b005e by Benjamin Peterson (pdox) in branch 'master':
bpo-31857: Make the behavior of USE_STACKCHECK deterministic (#4098)
https://github.com/python/cpython/commit/1896793520a49a6f97ae360c0b288967e56b005e


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31857>
_______________________________________

From report at bugs.python.org  Thu Oct 26 02:03:32 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Oct 2017 06:03:32 +0000
Subject: [issue31857] Make the behavior of USE_STACKCHECK deterministic
In-Reply-To: <1508807362.1.0.213398074469.issue31857@psf.upfronthosting.co.za>
Message-ID: <1508997812.74.0.213398074469.issue31857@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31857>
_______________________________________

From report at bugs.python.org  Thu Oct 26 02:04:13 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Oct 2017 06:04:13 +0000
Subject: [issue31866] clean out some more AtheOS code
In-Reply-To: <1508912423.08.0.213398074469.issue31866@psf.upfronthosting.co.za>
Message-ID: <1508997853.5.0.213398074469.issue31866@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, the configure.ac thing is some code that fails if you're running atheos.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31866>
_______________________________________

From report at bugs.python.org  Thu Oct 26 02:20:11 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Oct 2017 06:20:11 +0000
Subject: [issue28503] [Patch] '_crypt' module: fix implicit declaration of
 crypt(), use crypt_r() where available
In-Reply-To: <1477122775.81.0.204871394378.issue28503@psf.upfronthosting.co.za>
Message-ID: <1508998811.5.0.213398074469.issue28503@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This sgtm. Can you send a PR?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28503>
_______________________________________

From report at bugs.python.org  Thu Oct 26 02:55:16 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Oct 2017 06:55:16 +0000
Subject: [issue31866] clean out some more AtheOS code
In-Reply-To: <1508912423.08.0.213398074469.issue31866@psf.upfronthosting.co.za>
Message-ID: <1509000916.25.0.213398074469.issue31866@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 4eaf7f949069882e385f2297c9e70031caf9144c by Benjamin Peterson in branch 'master':
fixes bpo-31866: remove code pertaining to AtheOS support (#4115)
https://github.com/python/cpython/commit/4eaf7f949069882e385f2297c9e70031caf9144c


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31866>
_______________________________________

From report at bugs.python.org  Thu Oct 26 03:10:33 2017
From: report at bugs.python.org (David Bolen)
Date: Thu, 26 Oct 2017 07:10:33 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1509001833.56.0.213398074469.issue31430@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

I believe I've identified the issue, and put a workaround in place.

The 986b7ffc commit somehow affected which binary of mt.exe is being run (for version 5.2.3790.2076, 2005), changing from:
  C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64\mt.exe
to
  C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe
The 32-bit version is what is crashing, at least when trying to add the manifest to a 64-bit library (it does work for other manifest operations).

I thought the binary was just incompatible, but I located a later version of mt (6.3.9600.17336, 2012) under C:\Program Files (x86)\Windows Kits\8.1 for which both the 32-bit and 64-bit versions worked.  Of course, there was also the issue of why Win8 was working with the 5.2 32-bit version.

Then I noticed a .NET config file for the newer 6.3 mt to handle running on systems with .NET 4 but not 1.1 or 2.  As it turns out, the Win10 buildbot is .NET 4+ only, while the older 8.1 buildbot has frameworks back to .NET 2.  So that's probably what kept the Win8 buildbot from failing just like Win10.

What I did for now is borrow the .NET exe config files from mt 6.3 for use with the SDK mt 5.2 binaries, which looks like it's done the trick.


It might be best to restore the old behavior if possible so building works without the workaround, but I'm not sure how the binary is being determined.  None of the mt binaries are in the default path so must be found by the build process somehow.  Reverting to using env.bat with the latest source (so msbuild is found on the path) still ends up calling the 32-bit mt.  So something else in the changes must be influencing the binary choice.  And given that this only affects using the scripts to build 2.7 on a recently installed machine, hard to say if it's worth much effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Thu Oct 26 03:26:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Oct 2017 07:26:26 +0000
Subject: [issue30855] [2.7] test_tk: test_use() of test_tkinter.test_widgets
 randomly fails with "integer value too large to represent" on with AMD64
 Windows8 3.5
In-Reply-To: <1508967841.11.0.912454111764.issue30855@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaEtA+SobizGT8HNUv+S8h6VkjNOHDnppUbOAb=fxUYWA@mail.gmail.com>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh thank you Serhiy for the fix, this random bug was annoying!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30855>
_______________________________________

From report at bugs.python.org  Thu Oct 26 03:31:16 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 07:31:16 +0000
Subject: [issue30484] Garbage Collector can cause Segfault whilst iterating
 dictionary items
In-Reply-To: <1495802890.31.0.92287761621.issue30484@psf.upfronthosting.co.za>
Message-ID: <1509003076.39.0.213398074469.issue30484@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

PR 2248 (3.4) and PR 2396 (3.3) have been merged. I think this issue can be closed now.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30484>
_______________________________________

From report at bugs.python.org  Thu Oct 26 03:32:10 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 07:32:10 +0000
Subject: [issue30904] Python 3 logging HTTPHandler sends duplicate Host header
In-Reply-To: <1499782260.84.0.538162652134.issue30904@psf.upfronthosting.co.za>
Message-ID: <1509003130.02.0.213398074469.issue30904@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30904>
_______________________________________

From report at bugs.python.org  Thu Oct 26 03:42:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 07:42:05 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1509003725.38.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 41c56940c6edf3ea169332a6b039b6c8796f0475 by Serhiy Storchaka in branch 'master':
bpo-21720: Restore the Python 2.7 logic in handling a fromlist. (#4118)
https://github.com/python/cpython/commit/41c56940c6edf3ea169332a6b039b6c8796f0475


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Thu Oct 26 03:43:27 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 07:43:27 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1509003807.67.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is it worth to backport PR 4118 to 3.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:06:15 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Oct 2017 08:06:15 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1509005175.01.0.213398074469.issue21720@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given that the automated cherry-pick failed, I'd consider a 3.6 backport nice to have, but definitely not essential.

My rationale for that is that "from __future__ import unicode_literals" makes it fairly easy to stumble over the 2.7 variant of this error message, but we're not aware of a similarly implicit way of encountering the 3.x variant.

----------
stage: patch review -> backport needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:18:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 08:18:54 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509005934.45.0.213398074469.issue24920@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This issue already is fixed in 3.5 (see issue26801). The Stackoverflow question is related to 3.4 which is too old for getting this fix.

I'm wondering if it is worth to patch shutil.get_terminal_size() in IDLE so that it will return the size of PyShell output window (in characters).

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed
superseder:  -> Fix shutil.get_terminal_size() to catch AttributeError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:22:29 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 08:22:29 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1509006149.72.0.213398074469.issue21720@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4093
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:27:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 08:27:48 +0000
Subject: [issue30937] csv module examples miss newline='' when opening files
In-Reply-To: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za>
Message-ID: <1509006468.88.0.213398074469.issue30937@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 275d2d9c4663a1ea8d1f7c8778567a735b0372c1 by Berker Peksag (Ammar Askar) in branch 'master':
bpo-30937: Make usage of newline='' consistent in csv docs (GH-2730)
https://github.com/python/cpython/commit/275d2d9c4663a1ea8d1f7c8778567a735b0372c1


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30937>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:27:54 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Oct 2017 08:27:54 +0000
Subject: [issue30937] csv module examples miss newline='' when opening files
In-Reply-To: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za>
Message-ID: <1509006474.64.0.213398074469.issue30937@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4094

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30937>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:37:33 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 08:37:33 +0000
Subject: [issue30949] Provide assertion functions in unittest.mock
In-Reply-To: <1500302203.03.0.925103147939.issue30949@psf.upfronthosting.co.za>
Message-ID: <1509007053.16.0.213398074469.issue30949@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the report. This is a duplicate of issue 24651.

----------
components: +Library (Lib) -Tests
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Mock.assert* API is in user namespace
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30949>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:38:19 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 08:38:19 +0000
Subject: [issue30937] csv module examples miss newline='' when opening files
In-Reply-To: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za>
Message-ID: <1509007099.77.0.213398074469.issue30937@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 614ea48986f80d361043510ac3945f3dcd666c31 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-30937: Make usage of newline='' consistent in csv docs (GH-2730)
https://github.com/python/cpython/commit/614ea48986f80d361043510ac3945f3dcd666c31


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30937>
_______________________________________

From report at bugs.python.org  Thu Oct 26 04:39:50 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 08:39:50 +0000
Subject: [issue30937] csv module examples miss newline='' when opening files
In-Reply-To: <1500130085.47.0.354601054193.issue30937@psf.upfronthosting.co.za>
Message-ID: <1509007190.04.0.213398074469.issue30937@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Good catch, Pavel. Thanks! This is now fixed in 3.6 and 3.7 docs. Thanks for the patch, Ammar.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30937>
_______________________________________

From report at bugs.python.org  Thu Oct 26 05:02:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 09:02:59 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1509008579.23.0.213398074469.issue21720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2b5cbbb13c6c9138d04c3ca4eb7431f8c65d8e65 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-21720: Restore the Python 2.7 logic in handling a fromlist. (GH-4118) (#4128)
https://github.com/python/cpython/commit/2b5cbbb13c6c9138d04c3ca4eb7431f8c65d8e65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Thu Oct 26 05:03:53 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 09:03:53 +0000
Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message
In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>
Message-ID: <1509008633.53.0.213398074469.issue21720@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21720>
_______________________________________

From report at bugs.python.org  Thu Oct 26 05:54:42 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Oct 2017 09:54:42 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1509011682.46.0.213398074469.issue31803@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Alexander Belopolsky: "I was not aware of time.clock() depreciation before Victor brought this issue to my attention."

That's why the function now emits a DeprecationWarning :-)


Alexander Belopolsky: "time.clock() is a very well-known API eponymous to a venerable UNIX system call.  Its limitations and platform dependencies are very well-known as well."

I'm not sure with "platform dependencies are very well-known".

"clock" is a the most common name to "get the current time". The problem is that the exact clock used by time.clock() depends on the platforms, and that each clock has a different behaviour. That's where the PEP 418 tried to define correctly what are "clocks" when you care of the portability.


I'm not sure that we can find an agreement. This issue becomes annoying. I don't know what do do. Close the issue? Revert my commit? Ignore the discussion and work on something else? :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Thu Oct 26 06:03:13 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Oct 2017 10:03:13 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509012193.26.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"the bug should be fixed in all affected versions"

I don't understand why you insist to change Python 3.4 and Python 3.5. IMHO this issue only impacts OpenBSD.


"The current code in not correct on all platforms. We don't know how many of random bugs, hangs and crashes on other platforms are caused by this bug. I'm not surprised that it was caught on OpenBSD since the robustness and security of software is the goal of OpenBSD."

I'm not aware of these "random bugs, hangs and crashes on other platforms". Did you hear someone complaining about random crashes in Python?

We are running the Python suite multiple times per time on a large farm of buildbot workers. I  never saw the crashes that you mentionned.

IMHO it's very unlikely or impossible that _PyMem_DebugRawRealloc() erases bytes of a memory block that was just unallocated while another thread uses this new memory block for a new allocation. Most, if not all, calls to _PyMem_DebugRawRealloc() are protected by the GIL. If there is a single thread using the memory block, I think that it's perfectly fine to write after it's deallocated.

Well, maybe I'm plain wrong, and it's possible that shrinking a memory block makes the unallocator memory block really unaccessible, and that the memcpy() after the realloc() triggers a big crash. But I would like to *see* such crash to really be convinced :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Thu Oct 26 06:09:19 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 26 Oct 2017 10:09:19 +0000
Subject: [issue31872] SSL BIO is broken for internationalized domains
Message-ID: <1509012559.64.0.213398074469.issue31872@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

`SSLContext.wrap_bio` creates a new `SSLObject` instance with passed `server_hostname`.
The name becomes IDNA-decoded: `'xn--2qq421aovb6v1e3pu.xn--j6w193g'` is converted to `'?????.??'` by `SSLObject` constructor.

Than on SSL handshake `ssl.match_hostname()` is called with `sslobject.server_hostname` parameter (`'?????.??'` in my example).

But certificate for the site is contains IDNA-encoded DNS names:
```
{'OCSP': ('http://ocsp.comodoca4.com',),
 'caIssuers': ('http://crt.comodoca4.com/COMODOECCDomainValidationSecureServerCA2.crt',),
 'crlDistributionPoints': ('http://crl.comodoca4.com/COMODOECCDomainValidationSecureServerCA2.crl',),
 'issuer': ((('countryName', 'GB'),),
            (('stateOrProvinceName', 'Greater Manchester'),),
            (('localityName', 'Salford'),),
            (('organizationName', 'COMODO CA Limited'),),
            (('commonName',
              'COMODO ECC Domain Validation Secure Server CA 2'),)),
 'notAfter': 'Mar 28 23:59:59 2018 GMT',
 'notBefore': 'Sep 19 00:00:00 2017 GMT',
 'serialNumber': 'FBFE0BF7CACA6DDC15968410BAA1908D',
 'subject': ((('organizationalUnitName', 'Domain Control Validated'),),
             (('organizationalUnitName', 'PositiveSSL Multi-Domain'),),
             (('commonName', 'sni38752.cloudflaressl.com'),)),
 'subjectAltName': (('DNS', 'sni38752.cloudflaressl.com'),
                    ('DNS', '*.1km.hk'),
                    ('DNS', '*.acg-cafe.com'),
                    ('DNS', '*.acgapp.moe'),
                    ('DNS', '*.acgapp.net'),
                    ('DNS', '*.cosmatch.org'),
                    ('DNS', '*.dirimusik.com'),
                    ('DNS', '*.dirimusik.info'),
                    ('DNS', '*.downloadlagi.club'),
                    ('DNS', '*.downloadlaguaz.info'),
                    ('DNS', '*.farmprecision.com'),
                    ('DNS', '*.glowecommercialphotography.co.uk'),
                    ('DNS', '*.hypertechglobal.com'),
                    ('DNS', '*.hypertechglobal.hk'),
                    ('DNS', '*.infoku.download'),
                    ('DNS', '*.inimp3.com'),
                    ('DNS', '*.luciafitness.com.au'),
                    ('DNS', '*.merdeka.news'),
                    ('DNS', '*.promisecos.com'),
                    ('DNS', '*.promisecos.hk'),
                    ('DNS', '*.ps9architects.com'),
                    ('DNS', '*.rubaxeu.gq'),
                    ('DNS', '*.ruth-fox.com'),
                    ('DNS', '*.simmit.net.au'),
                    ('DNS', '*.startss.today'),
                    ('DNS', '*.xn--2qq421aovb6v1e3pu.xn--j6w193g'),
                    ('DNS', '*.xn--hhrw16aw6jizf.xn--j6w193g'),
                    ('DNS', '1km.hk'),
                    ('DNS', 'acg-cafe.com'),
                    ('DNS', 'acgapp.moe'),
                    ('DNS', 'acgapp.net'),
                    ('DNS', 'cosmatch.org'),
                    ('DNS', 'dirimusik.com'),
                    ('DNS', 'dirimusik.info'),
                    ('DNS', 'downloadlagi.club'),
                    ('DNS', 'downloadlaguaz.info'),
                    ('DNS', 'farmprecision.com'),
                    ('DNS', 'glowecommercialphotography.co.uk'),
                    ('DNS', 'hypertechglobal.com'),
                    ('DNS', 'hypertechglobal.hk'),
                    ('DNS', 'infoku.download'),
                    ('DNS', 'inimp3.com'),
                    ('DNS', 'luciafitness.com.au'),
                    ('DNS', 'merdeka.news'),
                    ('DNS', 'promisecos.com'),
                    ('DNS', 'promisecos.hk'),
                    ('DNS', 'ps9architects.com'),
                    ('DNS', 'rubaxeu.gq'),
                    ('DNS', 'ruth-fox.com'),
                    ('DNS', 'simmit.net.au'),
                    ('DNS', 'startss.today'),
                    ('DNS', 'xn--2qq421aovb6v1e3pu.xn--j6w193g'),
                    ('DNS', 'xn--hhrw16aw6jizf.xn--j6w193g')),
 'version': 3}
```

Match `'?????.??'` to `('DNS', 'xn--2qq421aovb6v1e3pu.xn--j6w193g')` obviously fails.

I see two possible solutions:

1. Always do IDNA encoding for `server_hostname` stored in ssl object.
2. Do two checks for both IDNA and original server hostname values. I don't sure if certificates always use IDNA-encoded DNS names only.

The fix is trivial, I'll make a Pull Request after choosing what option we want to support. Personally I'm inclined to second one.

P.S.
`requests` library is not affected because it uses `ssl.wrap_socket`.
The bug is reproducible for `asyncio` only (and maybe Tornado with `asyncio` `IOLoop`).

----------
assignee: christian.heimes
components: SSL
messages: 305042
nosy: asvetlov, christian.heimes, pitrou
priority: normal
severity: normal
status: open
title: SSL BIO is broken for internationalized domains
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31872>
_______________________________________

From report at bugs.python.org  Thu Oct 26 06:09:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Oct 2017 10:09:26 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509012566.48.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

"PR 4119 is too complex for a bugfix (especially if backport it to 3.5 and 3.4). It can introduce other regressions."

Which kind of regression do you expect? Something like a crash?


"The performance hit is not the only issue. Allocating a temporary buffer can change the structure of "holes" in memory. As result some memory related bugs can be reproducible only in release mode."

Can you please elaborate how the exact memory layout can trigger or not bugs in the code?

I'm not saying that you are right or wrong. I just fail to see why the memory address and "holes" would trigger or not bugs.

What I can understand is a subtle behaviour change if realloc() returns the same memory block or a new memory block. But we cannot control that.

I'm not sure that allocating "copy" before realloc() would impact the behaviour of realloc(). The common case is that a memory block is a few bytes smaller, and so the realloc returns the same memory block, but now becomes able to use the unallocated bytes for a new allocation later, no?


"Maybe it is enough to erase only few bytes at the start and end of the freed area. The copy can be saved in local variables, without involving the heap. This solution still will be enough complex, and I think it can be applied only to 3.7. But the bug should be fixed in all affected versions."

If we must make a choice, I would prefer to keep the current behaviour: make sure that unallocated bytes are erased. Catching code reading unallocated bytes is the most important feature of debug hooks, no?

I dislike the idea of only erasing "some" bytes: this change may prevent to detect some bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Thu Oct 26 06:14:01 2017
From: report at bugs.python.org (Akos Kiss)
Date: Thu, 26 Oct 2017 10:14:01 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1509012841.88.0.213398074469.issue31863@psf.upfronthosting.co.za>


Akos Kiss <akosthekiss at gmail.com> added the comment:

`taskkill /F` sets exit code to 1, indeed. (Confirmed by experiment. Cannot find this behaviour documented, though.)

On the other hand, MS Docs state (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/signal#remarks) that termination by a signal "terminates the calling program with exit code 3". (So, there may be other "valid" exit codes, too.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Thu Oct 26 06:25:41 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 26 Oct 2017 10:25:41 +0000
Subject: [issue31872] SSL BIO is broken for internationalized domains
In-Reply-To: <1509012559.64.0.213398074469.issue31872@psf.upfronthosting.co.za>
Message-ID: <1509013541.23.0.213398074469.issue31872@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31872>
_______________________________________

From report at bugs.python.org  Thu Oct 26 07:31:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 11:31:51 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1509017511.8.0.213398074469.issue28936@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is it correct that the parameter can be annotated in the function body?

def f(x):
    x: int

Or that the local variable can be annotated after assignment?

def f():
    x = 1
    x: int

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Thu Oct 26 07:46:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 11:46:04 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1508245245.67.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <1509018364.77.0.213398074469.issue31803@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is very bad, that the function with such attractive name has different meaning on Windows and Unix. I'm sure that virtually all uses of clock() are broken because its behavior on other platform than used by the author of the code. Adding a DeprecationWarning and finally removing it looks right thing to me. But we should keep it while 2.7 and versions older than 3.3 are in use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Thu Oct 26 08:59:59 2017
From: report at bugs.python.org (Akos Kiss)
Date: Thu, 26 Oct 2017 12:59:59 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1509022799.06.0.213398074469.issue31863@psf.upfronthosting.co.za>


Akos Kiss <akosthekiss at gmail.com> added the comment:

A follow-up: in addition to `taskkill`, I've taken a look at another "official" way for killing processes, the `Stop-Process` PowerShell cmdlet (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-process?view=powershell-5.1). Yet again, documentation is scarce on what the exit code of the terminated process will be. But PowerShell and .NET code base is open sourced, so I've dug a bit deeper and found that `Stop-Process` is based on `System.Diagnostics.Process.Kill()` (https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Management/commands/management/Process.cs#L1240), while `Process.Kill()` uses the `TerminateProcess` Win32 API (https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs#L93). Interestingly, `TerminateProcess` is called with -1 (this was surprising, to me at least, as exit code is unsigned on Windows AFAIK).

Therefore, I've added two new "kill" implementations to my original code experiment (wont repeat the whole code here, just the additions):

```py
def kill_with_taskkill(proc):
    print('kill child with taskkill /F')
    subprocess.run(['taskkill', '/F', '/pid', '%s' % proc.pid], check=True)

def kill_with_stopprocess(proc):
    print('kill child with powershell stop-process')
    subprocess.run(['powershell', 'stop-process', '%s' % proc.pid], check=True)
```

And I got:

```
run subprocess child with subprocess-taskkill
child process started with subprocess-taskkill
kill child with taskkill /F
SUCCESS: The process with PID 4024 has been terminated.
child terminated with 1
run subprocess child with subprocess-stopprocess
child process started with subprocess-stopprocess
kill child with powershell stop-process
child terminated with 4294967295

run multiprocessing child with multiprocessing-taskkill
child process started with multiprocessing-taskkill
kill child with taskkill /F
SUCCESS: The process with PID 5988 has been terminated.
child terminated with 1
run multiprocessing child with multiprocessing-stopprocess
child process started with multiprocessing-stopprocess
kill child with powershell stop-process
child terminated with 4294967295
```

My takeaways from the above are that
1) Windows is not consistent across itself,
2) 1 is not the only "valid" "terminated forcibly" exit code, and
3) negative exit code does not work, even if MS itself tries to use it.

BTW, I really think that killing a process with a code of 1 is questionable, as quite some apps return 1 themselves just to signal error (but proper termination). This makes it hard to tell applications' own error signaling and forced kills apart. But that's a personal opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:01:35 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 26 Oct 2017 13:01:35 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1509022895.35.0.213398074469.issue30697@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Checking the test_exceptions test cases that are added by PR 2327 on the current master branch, before the merge of PR 2327:
* test_recursion_normalizing_exception still fails (SIGABRT on a debug build and SIGSEGV otherwise)
* test_recursion_normalizing_infinite_exception is ok as expected
* test_recursion_normalizing_with_no_memory still fails with a SIGSEGV

The attached script except_raises_except.py exercises case 3) described in msg231933. The output is as follows when PR 2327 is applied and confirms that the ResourceWarning is now printed:

Traceback (most recent call last):
  File "except_raises_except.py", line 11, in <module>
    generator.throw(MyException)
  File "except_raises_except.py", line 7, in gen
    yield
  File "except_raises_except.py", line 3, in __init__
    raise MyException
  File "except_raises_except.py", line 3, in __init__
    raise MyException
  File "except_raises_except.py", line 3, in __init__
    raise MyException
  [Previous line repeated 495 more times]
RecursionError: maximum recursion depth exceeded while calling a Python object
sys:1: ResourceWarning: unclosed file <_io.FileIO name='except_raises_except.py' mode='rb' closefd=True>

----------
versions:  -Python 3.5
Added file: https://bugs.python.org/file47239/except_raises_except.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:09:08 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 26 Oct 2017 13:09:08 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1509023348.34.0.213398074469.issue30697@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:


New changeset 56d1f5ca32892c7643eb8cee49c40c1644f1abfe by xdegaye in branch 'master':
bpo-30697: Fix PyErr_NormalizeException() when no memory (GH-2327)
https://github.com/python/cpython/commit/56d1f5ca32892c7643eb8cee49c40c1644f1abfe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:09:44 2017
From: report at bugs.python.org (Tom Floyer)
Date: Thu, 26 Oct 2017 13:09:44 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1509023384.09.0.213398074469.issue31811@psf.upfronthosting.co.za>


Change by Tom Floyer <tomfloyer at icloud.com>:


----------
keywords: +patch
pull_requests: +4095
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:15:32 2017
From: report at bugs.python.org (David Antonini)
Date: Thu, 26 Oct 2017 13:15:32 +0000
Subject: [issue31873] Inconsistent capitalization of proper noun - Unicode.
Message-ID: <1509023732.92.0.213398074469.issue31873@psf.upfronthosting.co.za>


New submission from David Antonini <davidantonini at hotmail.com>:

Make 'unicode'/'Unicode' capitalization consistent.
'Unicode' is a proper noun, and as such should be capitalized. 

I submitted a pull request correcting the inconsistent capitalization in the Unicode page of the Documentation - Doc/c-api/unicode.rst - capitalizing 12 errant instances to reflect the correct capitalization in most of the document. I was then requested to open an issue here for discussion.

----------
assignee: docs at python
components: Documentation
messages: 305050
nosy: docs at python, toonarmycaptain
priority: normal
pull_requests: 4096
severity: normal
status: open
title: Inconsistent capitalization of proper noun - Unicode.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31873>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:41:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 13:41:52 +0000
Subject: [issue31873] Inconsistent capitalization of proper noun - Unicode.
In-Reply-To: <1509023732.92.0.213398074469.issue31873@psf.upfronthosting.co.za>
Message-ID: <1509025312.89.0.213398074469.issue31873@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I agree that the inconsistency should be fixed. But I'm not sure that we should use the words "an Unicode object" in Python 3.

In many similar cases ("a bytes object", "a type object", "a module object") the name of Python type is used. "unicode" was a name of Python type in Python 2. In Python 3 it is "str". The term "Unicode string" also is widely used. Should not we use "a str object", "a string object", "a Unicode string" or "a Unicode string object" in the C API documentation?

----------
components: +Unicode
nosy: +benjamin.peterson, ezio.melotti, haypo, lemburg, martin.panter, r.david.murray, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31873>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:43:11 2017
From: report at bugs.python.org (Isaiah Peng)
Date: Thu, 26 Oct 2017 13:43:11 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1509025391.01.0.213398074469.issue16737@psf.upfronthosting.co.za>


Isaiah Peng <issaria at gmail.com> added the comment:

Not sure if it's stated before, this difference of behavior also has other effects, e.g.

$ python -m test.test_traceback

# Ran 61 tests in 0.449s
# FAILED (failures=5)

This is because the loader associated with the module get confused, it loaded the original module as the proper module and then the module changed name to __main__ but the loader is still associated with the old module name, so call to `get_source` fails.

$ cat > test_m.py
print(__loader__.get_source(__name__))

$ python -m test_m

# ImportError: loader for test_m cannot handle __main__

----------
nosy: +isaiah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Thu Oct 26 09:50:27 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Oct 2017 13:50:27 +0000
Subject: [issue31873] Inconsistent capitalization of proper noun - Unicode.
In-Reply-To: <1509023732.92.0.213398074469.issue31873@psf.upfronthosting.co.za>
Message-ID: <1509025827.16.0.213398074469.issue31873@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It may be a proper noun, but it is conventionally spelled with a lowercase letter when referring to the type/object.  It would be spelled with an upper case letter when referring to the *standard*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31873>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:01:14 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Oct 2017 14:01:14 +0000
Subject: [issue31874] [feature] runpy.run_module should mimic script launch
 behavior for sys.path
Message-ID: <1509026474.72.0.213398074469.issue31874@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In [this comment](https://bugs.python.org/issue16737#msg282872) I describe an issue whereby launching an application via runpy.run_module (aka python -m) produces different and unexpected behavior than running the same app via an entry script.

In [this followup comment](https://bugs.python.org/issue16737#msg304662), I provide more detail on why a user might expect for run_module to mimic the behavior of launching a script.

[Nick suggests](https://bugs.python.org/issue16737#msg304707):

> Update sys.path[0] based on __main__.__spec__.origin after [resolving] __main__.__spec__. That way it will only stay as the current directory if the module being executed is in a subdirectory of the current directory, and will otherwise be updated appropriately for wherever we actually found the main module.

----------
messages: 305054
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: [feature] runpy.run_module should mimic script launch behavior for sys.path
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31874>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:01:54 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Oct 2017 14:01:54 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1509026514.1.0.213398074469.issue16737@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've filed a separate request here for the sys.path[0] aspect: https://bugs.python.org/issue31874

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:05:19 2017
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 26 Oct 2017 14:05:19 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1509026719.32.0.213398074469.issue23990@psf.upfronthosting.co.za>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

Hello everyone,

Is anyone still interested in fixing this bug and help with whatever PEP drafting was needed for convincing people?

I would sketch up a draft but for me at least it's not clear what are the disadvantages of not fixing this, so I could use some help making a unbiased document that won't attract tons of negativity and contempt (yet again).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:07:12 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Oct 2017 14:07:12 +0000
Subject: [issue31874] [feature] runpy.run_module should mimic script launch
 behavior for sys.path
In-Reply-To: <1509026474.72.0.213398074469.issue31874@psf.upfronthosting.co.za>
Message-ID: <1509026832.38.0.213398074469.issue31874@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

At first, I didn't understand why one wouldn't simply omit sys.path[0], similar to what scripts do, but then I realized that Nick was aware of a common use-case that I was overlooking - that `python -m` may be used to launch behavior in a local package - in which case it's relevant and important that sys.path[0] == ''.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31874>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:07:47 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Oct 2017 14:07:47 +0000
Subject: [issue31874] [feature] runpy.run_module should mimic script launch
 behavior for sys.path
In-Reply-To: <1509026474.72.0.213398074469.issue31874@psf.upfronthosting.co.za>
Message-ID: <1509026867.5.0.213398074469.issue31874@psf.upfronthosting.co.za>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31874>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:07:58 2017
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Oct 2017 14:07:58 +0000
Subject: [issue31874] [feature] runpy.run_module should mimic script launch
 behavior for sys.path
In-Reply-To: <1509026474.72.0.213398074469.issue31874@psf.upfronthosting.co.za>
Message-ID: <1509026878.91.0.213398074469.issue31874@psf.upfronthosting.co.za>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31874>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:16:28 2017
From: report at bugs.python.org (Gareth Moger)
Date: Thu, 26 Oct 2017 14:16:28 +0000
Subject: [issue31875] Error 0x80070642: Failed to install MSI package.
Message-ID: <1509027387.81.0.213398074469.issue31875@psf.upfronthosting.co.za>


New submission from Gareth Moger <garethmoger at googlemail.com>:

I had my work computer re-imaged this week but Python 3.6.1 is gone and I am unable to install.

I have tried to completely remove it with CCleaner and any other references I found but it still will not install.  I am installing the same version as before.

Following the advice from another post, I installed on another machine and then copied the folder onto my work machine but was unable to uninstall/repair as described.

Attached is the log file.

----------
components: Installation
files: Python 3.6.1 (32-bit)_20171026151143.log
messages: 305058
nosy: Gareth Moger
priority: normal
severity: normal
status: open
title: Error 0x80070642: Failed to install MSI package.
versions: Python 3.6
Added file: https://bugs.python.org/file47240/Python 3.6.1 (32-bit)_20171026151143.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31875>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:18:56 2017
From: report at bugs.python.org (Gareth Moger)
Date: Thu, 26 Oct 2017 14:18:56 +0000
Subject: [issue31875] Error 0x80070642: Failed to install MSI package.
In-Reply-To: <1509027387.81.0.213398074469.issue31875@psf.upfronthosting.co.za>
Message-ID: <1509027536.02.0.213398074469.issue31875@psf.upfronthosting.co.za>


Change by Gareth Moger <garethmoger at googlemail.com>:


Added file: https://bugs.python.org/file47241/Python 3.6.1 (32-bit)_20171026151143.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31875>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:21:36 2017
From: report at bugs.python.org (Hery)
Date: Thu, 26 Oct 2017 14:21:36 +0000
Subject: [issue31876] python363.chm includes gibberish
Message-ID: <1509027696.53.0.213398074469.issue31876@psf.upfronthosting.co.za>


New submission from Hery <weiyong.mao at gmail.com>:

Just Open https://www.python.org/ftp/python/3.6.3/python363.chm 

And click the first page, it says "What? New in Python". And most of pages the chm file include some gibberish.

----------
assignee: docs at python
components: Documentation
messages: 305059
nosy: Nim, docs at python
priority: normal
severity: normal
status: open
title: python363.chm includes gibberish
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31876>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:35:15 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 14:35:15 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509028515.78.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The current code OBVIOUSLY is wrong. Bytes are erased if q == oldq && nbytes < original_nbytes. But q == oldq only if realloc() returns the new address 2*sizeof(size_t) bytes larger than its argument. This is virtually never happen on other platforms because _PyMem_DebugRawRealloc() usually used with blocks larger than 2*sizeof(size_t) bytes and the system realloc() don't shrink the block at left (this is implementation detail). Thus this code is virtually dead on other platforms. It doesn't detect shrinking memory block in-place.

After fixing *this* bug, we have encountered with *other* bug, related to overwriting the freed memory.

I don't see reasons of keeping an obviously wrong code. When fix the first bug we will need to fix the other bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:54:59 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 14:54:59 +0000
Subject: [issue31877] Build fails on Cython since issue28180
Message-ID: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

I'm trying once again to get the test suite up to snuff on Cygwin so I can start running a buildbot (particularly now that PEP 539 is done).  However, as of issue28180 the build fails with:

gcc    -o python.exe Programs/python.o libpython3.7m.dll.a -lintl -ldl    -lm
Programs/python.o: In function `main':
./Programs/python.c:81: undefined reference to `_Py_LegacyLocaleDetected'
./Programs/python.c:81:(.text.startup+0x86): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_Py_LegacyLocaleDetected'
./Programs/python.c:82: undefined reference to `_Py_CoerceLegacyLocale'
./Programs/python.c:82:(.text.startup+0x19f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_Py_CoerceLegacyLocale'
collect2: error: ld returned 1 exit status

It seems _Py_LegacyLocaleDetected and _PyCoerceLegacyLocale are missing the necessary PyAPI_FUNC declarations in pylifecycle.h.

----------
messages: 305061
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Build fails on Cython since issue28180
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:58:25 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 14:58:25 +0000
Subject: [issue31877] Build fails on Cython since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509029905.18.0.213398074469.issue31877@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
keywords: +patch
pull_requests: +4097
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Thu Oct 26 10:59:10 2017
From: report at bugs.python.org (David Antonini)
Date: Thu, 26 Oct 2017 14:59:10 +0000
Subject: [issue31873] Inconsistent capitalization of proper noun - Unicode.
In-Reply-To: <1509023732.92.0.213398074469.issue31873@psf.upfronthosting.co.za>
Message-ID: <1509029950.19.0.213398074469.issue31873@psf.upfronthosting.co.za>


David Antonini <davidantonini at hotmail.com> added the comment:

Does the Unicode documentation currently conform to that convention, or does it require editing? 

It appears to me that a lot of cases where reference to "Unicode object" is currently capitalised (most of them, in fact) may need to be modified. 
However, it would seem that there is a grey area in making a distinction between reference to the unicode type as implemented in Python and reference to the standard as a descriptor of the format of an object? The way I read there a lot of the cases are in essence a reference to both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31873>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:03:08 2017
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Oct 2017 15:03:08 +0000
Subject: [issue31877] Build fails on Cython since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509030188.61.0.213398074469.issue31877@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +haypo, ncoghlan, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:18:26 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 26 Oct 2017 15:18:26 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1509031106.39.0.213398074469.issue23990@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking as closed.  This can be reopened if a PEP is submitted and is favorably received.

----------
assignee: rhettinger -> 
status: open -> closed
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:22:37 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 26 Oct 2017 15:22:37 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1509031357.96.0.213398074469.issue30697@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +4098
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:28:18 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Oct 2017 15:28:18 +0000
Subject: [issue31877] Build fails on Cython since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509031698.89.0.213398074469.issue31877@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:30:09 2017
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 26 Oct 2017 15:30:09 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1509031809.65.0.213398074469.issue23990@psf.upfronthosting.co.za>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

It should be open for getting some visibility, as I need some help here -  Raymond, I hope you can find a way to be hospitable here and stop with the kindergarten behavior.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:31:27 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 15:31:27 +0000
Subject: [issue2445] Use The CygwinCCompiler Under Cygwin
In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za>
Message-ID: <1509031887.29.0.213398074469.issue2445@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
pull_requests: +4099
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2445>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:42:21 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 15:42:21 +0000
Subject: [issue31878] Cygwin: _socket module does not compile due to missing
 ioctl declaration
Message-ID: <1509032541.6.0.213398074469.issue31878@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

On Cygwin, ioctl() is found in sys/ioctl.h (as on Darwin).  Without adding something to the effect of

#ifdef __CYGWIN__
# include <sys/ioctl.h>
#endif

the _socket module cannot compile on Cygwin.  A fix was this was included in the (rejected) https://bugs.python.org/issue29718; this issue is just as a reminder that it remains an issue and to have a bug report to attach a more focused PR to.

----------
messages: 305065
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Cygwin: _socket module does not compile due to missing ioctl declaration
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31878>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:45:49 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 15:45:49 +0000
Subject: [issue31878] Cygwin: _socket module does not compile due to missing
 ioctl declaration
In-Reply-To: <1509032541.6.0.213398074469.issue31878@psf.upfronthosting.co.za>
Message-ID: <1509032749.04.0.213398074469.issue31878@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
keywords: +patch
pull_requests: +4100
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31878>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:48:50 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 26 Oct 2017 15:48:50 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1509032930.07.0.213398074469.issue30697@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:


New changeset 4b27d51222be751125e6800453a39360a2dec11d by xdegaye in branch '3.6':
[3.6] bpo-30697: Fix PyErr_NormalizeException() when no memory (GH-2327). (#4135)
https://github.com/python/cpython/commit/4b27d51222be751125e6800453a39360a2dec11d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:51:17 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 26 Oct 2017 15:51:17 +0000
Subject: [issue30697] segfault in PyErr_NormalizeException() after memory
 exhaustion
In-Reply-To: <1497792581.23.0.578886308028.issue30697@psf.upfronthosting.co.za>
Message-ID: <1509033077.15.0.213398074469.issue30697@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30697>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:52:49 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 15:52:49 +0000
Subject: [issue31828] Support Py_tss_NEEDS_INIT outside of static
 initialisation
In-Reply-To: <1508515676.46.0.213398074469.issue31828@psf.upfronthosting.co.za>
Message-ID: <1509033169.31.0.213398074469.issue31828@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31828>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:54:06 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 26 Oct 2017 15:54:06 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1509033246.0.0.213398074469.issue22898@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Fixed by issue 30697.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:55:51 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Oct 2017 15:55:51 +0000
Subject: [issue31873] Inconsistent capitalization of proper noun - Unicode.
In-Reply-To: <1509023732.92.0.213398074469.issue31873@psf.upfronthosting.co.za>
Message-ID: <1509033351.62.0.213398074469.issue31873@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In this case I think the cost of editing for consistency may be higher than the value, especially since as you say there are ambiguous cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31873>
_______________________________________

From report at bugs.python.org  Thu Oct 26 11:56:01 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 15:56:01 +0000
Subject: [issue31877] Build fails on Cython since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509033361.04.0.213398074469.issue31877@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> ncoghlan
components: +Interpreter Core, Windows
nosy: +paul.moore, steve.dower, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Thu Oct 26 12:04:18 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Oct 2017 16:04:18 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1509033858.39.0.213398074469.issue23990@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ionel please give commenters the benefit of the doubt.  In this case, Raymond is merely articulating our policy: if something is in pre-PEP stage we don't generally keep issues open in the tracker.  We open issues for PEPs when they get to the implementation stage.

So, if you want to pursue this, the best forum is the python-ideas mailing list, followed eventually by the python-dev mailing list.  That is the best way to get visibility, not through a bug tracker with thousands of open issues.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Thu Oct 26 12:16:31 2017
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 26 Oct 2017 16:16:31 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1509034591.38.0.213398074469.issue23990@psf.upfronthosting.co.za>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

Alright, now it makes sense. Thank you for writing a thoughtful response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Thu Oct 26 12:19:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 16:19:08 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1509034748.93.0.213398074469.issue31415@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4101

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Thu Oct 26 12:22:03 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 16:22:03 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1509034923.76.0.213398074469.issue31415@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The importtime option is cached only if it is set. If it is not set (the common case), it is not cached.

PR 4138 makes it be cached in the common case and improves errors handling.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Thu Oct 26 13:01:08 2017
From: report at bugs.python.org (Robert)
Date: Thu, 26 Oct 2017 17:01:08 +0000
Subject: [issue31879] Launcher fails on custom command starting with "python"
Message-ID: <1509037268.43.0.213398074469.issue31879@psf.upfronthosting.co.za>


New submission from Robert <lma at posteo.de>:

In the "py.ini" file it is possible to specifiy customized commands (see https://www.python.org/dev/peps/pep-0397/#customized-commands).

Unfortunately it is not possible to specify custom commands beginning with  one of the buildin names (i.e. "python" or "/usr/bin/python"). 

This means that if I want to provide a virtual command like "python-xyz" I get an error message "Invalid version specification: '-xyz'" instead of running the executable assigned to python-xyz.

I would provide a Pullrequest if you accept this change in behaviour.

----------
components: Windows
messages: 305072
nosy: mrh1997, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Launcher fails on custom command starting with "python"
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31879>
_______________________________________

From report at bugs.python.org  Thu Oct 26 13:09:27 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 26 Oct 2017 17:09:27 +0000
Subject: [issue30904] Python 3 logging HTTPHandler sends duplicate Host header
In-Reply-To: <1499782260.84.0.538162652134.issue30904@psf.upfronthosting.co.za>
Message-ID: <1509037767.85.0.213398074469.issue30904@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30904>
_______________________________________

From report at bugs.python.org  Thu Oct 26 13:23:38 2017
From: report at bugs.python.org (John Brearley)
Date: Thu, 26 Oct 2017 17:23:38 +0000
Subject: [issue31880] subprocess process interaction with IDLEX GUI causes
 pygnuplot silent failures
Message-ID: <1509038618.41.0.213398074469.issue31880@psf.upfronthosting.co.za>


New submission from John Brearley <brearley at bell.net>:

There is an interesting interaction between the IDLEX GUI and subprocess module that causes pygnuplot silent failures. The example.py script below works fine when run from the WinPython Command Prompt.exe terminal window. The script will popup a new window from gnuplot with the desired graph, and in the same directory save the generated raw data as example.out and the generated graph as example.pdf. If you erase the generated files and then run the same script via the IDLEX GUI, there is no graph window created and only the raw data example.out file is created. There are no error messages.

The PyGnuplot module sets up a subprocess.Popen pipe as persistant connection to the gnuplot.exe utility. This allows the top level script to send multiple commands to gnuplot to compose the desired graph, and then finally save the file to disk. This all works fine when run from the WinPython Command Prompt.exe terminal window. However something subtle is breaking when the same script is run from the IDLEX GUI environment. It is not at all obvious if the subprocess module is not as forgiving as it needs to be of the IDLEX GUI input or if the IDLEX GUI is breaking the rules somewhere. I will start by asking the subprocess module team to comment.

I did try adding some trace code to the PyGnuplot.py module. In particular I turned on stdout=subprocess.PIPE  and stderr=subprocess.PIPE. I did proc.poll() before/after the command is sent to gnuplot. Interestingly, when I did proc.communicate(timeout=0) to do an immediate read for any stdout/err data, this seems to cause the
 subsequent write to the pipe.stdin to fail, saying the file is already closed. In another learning exercise script for subprocess, the communicate() method does not seem to interfere with the pipe behavior.

This issue is quite repeatable on demand. I set up a second PC and reproduced the issue on demand on the second PC. I am using WinPython 3.6.1 on Windows 7 with gnuplot 5.2.0 on both PC.

Here are the links to the various components needed to setup the environment to reproduce this issue:
1) gnuplot 5.2.0   https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.0/
2) pygnuplot 0.10.0  https://pypi.python.org/pypi/PyGnuplot/0.10.0
3) There is a one-line fix to PyGnuplot.py needed   https://github.com/benschneider/PyGnuplot/blob/master/PyGnuplot.py
4) example.py script  https://github.com/benschneider/PyGnuplot/blob/master/example.py

WinPython 3.6.1 installer comes with subprocess.py as part of the package, no version info that I can find.

When installing gnuplot there is an advanced option to check on that will automatically update your PATH variable. If you dont do this, then you must manully add "C:\gnuplot\bin" (or whatever the directory is)
 to your PATH variable. To check if gnuplot is correctly installed, from a DOS prompt terminal window, type "gnuplot -V". You should get a one line response "gnuplot 5.2 patchlevel 0".

----------
components: Interpreter Core, Windows
messages: 305073
nosy: jbrearley, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess process interaction with IDLEX GUI causes pygnuplot silent failures
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31880>
_______________________________________

From report at bugs.python.org  Thu Oct 26 13:30:12 2017
From: report at bugs.python.org (Steve Dower)
Date: Thu, 26 Oct 2017 17:30:12 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1509039012.33.0.213398074469.issue31430@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

Are you able to install .NET 3.5 on the Windows 10 machine? This is basically a requirement for the VC9 toolset (it's compatible with .NET 2.0 so should fulfil that requirement).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Thu Oct 26 13:32:23 2017
From: report at bugs.python.org (Erik Bray)
Date: Thu, 26 Oct 2017 17:32:23 +0000
Subject: [issue16135] Removal of OS/2 support
In-Reply-To: <1349389207.71.0.143036356134.issue16135@psf.upfronthosting.co.za>
Message-ID: <1509039143.72.0.213398074469.issue16135@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
pull_requests: +4102

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16135>
_______________________________________

From report at bugs.python.org  Thu Oct 26 13:58:04 2017
From: report at bugs.python.org (xoviat)
Date: Thu, 26 Oct 2017 17:58:04 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1508994112.2.0.213398074469.issue20486@psf.upfronthosting.co.za>
Message-ID: <CAKXb8mFj+LwXZp6EvE3ctuDg5Qev8TPUezC1RwmMMzuKN5141g@mail.gmail.com>


xoviat <xoviat at gmail.com> added the comment:

Unfortunately, this issue has taken on a much lower importance for me, and
as such, I won't be able to address it. Sorry about that.

2017-10-26 0:01 GMT-05:00 Berker Peksag <report at bugs.python.org>:

>
> Berker Peksag <berker.peksag at gmail.com> added the comment:
>
> xoviat, would you like to send your patch as a pull request on GitHub? It
> would be nice to add a simple test that the new Close() works correctly. I
> can do that if you don't have time, thank you!
>
> Steve, can we apply this to bugfix branches?
>
> ----------
> versions:  -Python 3.5
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue20486>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:05:09 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Oct 2017 18:05:09 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509041109.8.0.213398074469.issue24920@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If one starts IDLE from a command-line console (python -m idlelib) or Python console (import idlelib.idle), sys.__stdout__ is the TextIOWraper for that console and .fileno() returns 1.  .get_terminal_size() will then return the console size.  The exception occurs when IDLE is  started from an icon.

Implementing David's suggestion for shutil will be easy: insert just before the fileno call
    if not sys.__stdout__: raise ValueError()
This is what os.get_terminal_size() raises on IDLE.  Comments in the code in posixpath.c make it clear that this is intended guis and the low_level os function.

This came up today on Stackoverflow when someone tried to use matplotlib.pyplot, which calls os.get_terminal_size, on IDLE.
https://stackoverflow.com/questions/46921087/pyplot-with-idle
(Patching shutil will not help for the os call.)

----------
resolution: out of date -> 
stage: resolved -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:06:13 2017
From: report at bugs.python.org (Tom Floyer)
Date: Thu, 26 Oct 2017 18:06:13 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1509041173.72.0.213398074469.issue31810@psf.upfronthosting.co.za>


Change by Tom Floyer <tomfloyer at icloud.com>:


----------
pull_requests: +4103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:07:17 2017
From: report at bugs.python.org (Tom Floyer)
Date: Thu, 26 Oct 2017 18:07:17 +0000
Subject: [issue31811] async and await missing from keyword list in lexical
 analysis doc
In-Reply-To: <1508340723.02.0.213398074469.issue31811@psf.upfronthosting.co.za>
Message-ID: <1509041237.02.0.213398074469.issue31811@psf.upfronthosting.co.za>


Tom Floyer <tomfloyer at icloud.com> added the comment:

I've added those keywords to documentation master branch.

----------
nosy: +tomfloyer
pull_requests: +4104

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31811>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:32:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 18:32:42 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509042762.59.0.213398074469.issue24920@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What do you want to do Terry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:33:29 2017
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Oct 2017 18:33:29 +0000
Subject: [issue31810] Travis CI,
 buildbots: run "make smelly" to check if CPython leaks symbols
In-Reply-To: <1508340179.09.0.213398074469.issue31810@psf.upfronthosting.co.za>
Message-ID: <1509042809.14.0.213398074469.issue31810@psf.upfronthosting.co.za>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
pull_requests:  -4103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31810>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:35:02 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 18:35:02 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509042902.51.0.213398074469.issue24920@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Patching shutil will help for pandas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:49:21 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 18:49:21 +0000
Subject: [issue30553] Add HTTP Response code 421
In-Reply-To: <1496407832.3.0.808781068022.issue30553@psf.upfronthosting.co.za>
Message-ID: <1509043761.5.0.213398074469.issue30553@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 52ad72dd0a5a56414cc29b7c9b03259169825f35 by Berker Peksag (Vitor Pereira) in branch 'master':
bpo-30553: Add status code 421 to http.HTTPStatus (GH-2589)
https://github.com/python/cpython/commit/52ad72dd0a5a56414cc29b7c9b03259169825f35


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30553>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:50:50 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 18:50:50 +0000
Subject: [issue30553] Add HTTP Response code 421
In-Reply-To: <1496407832.3.0.808781068022.issue30553@psf.upfronthosting.co.za>
Message-ID: <1509043850.81.0.213398074469.issue30553@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you Julien (for the report) and Vitor (for the patch)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30553>
_______________________________________

From report at bugs.python.org  Thu Oct 26 14:59:08 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Oct 2017 18:59:08 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509044348.29.0.213398074469.issue24920@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am preparing a PR for shutil.get_window_size.  Pyplot should probably call that instead of the os version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 15:10:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 19:10:47 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509045047.96.0.213398074469.issue24920@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think it is better to open a new issue for a new feature. The bug reported in this issue two years ago already is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 15:19:54 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 Oct 2017 19:19:54 +0000
Subject: [issue24920] shutil.get_terminal_size throws AttributeError
In-Reply-To: <1440387314.74.0.165641645143.issue24920@psf.upfronthosting.co.za>
Message-ID: <1509045594.98.0.213398074469.issue24920@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Uh, sorry for the noise. I see now that shutil was already patched by Victor and you in #26801, so that it already works with IDLE started from an icon.  So now I don't understand your last comment, "Patching shutil will help for pandas."

----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24920>
_______________________________________

From report at bugs.python.org  Thu Oct 26 15:34:15 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 Oct 2017 19:34:15 +0000
Subject: [issue28281] Remove year limits from calendar
In-Reply-To: <1474922646.39.0.781731359123.issue28281@psf.upfronthosting.co.za>
Message-ID: <1509046455.22.0.213398074469.issue28281@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:


New changeset 66c88ce30ca2b23daa37038e1a3c0de98f241f50 by Alexander Belopolsky in branch 'master':
Closes bpo-28281: Remove year (1-9999) limits on the weekday() function. (#4109)
https://github.com/python/cpython/commit/66c88ce30ca2b23daa37038e1a3c0de98f241f50


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28281>
_______________________________________

From report at bugs.python.org  Thu Oct 26 15:39:11 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 26 Oct 2017 19:39:11 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1509046751.07.0.213398074469.issue28936@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Those seem things that the type checker should complain about, but I don't think Python should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Thu Oct 26 16:06:59 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 20:06:59 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1509048419.8.0.213398074469.issue20486@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +4105

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Thu Oct 26 16:27:23 2017
From: report at bugs.python.org (David Bolen)
Date: Thu, 26 Oct 2017 20:27:23 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1509049643.33.0.213398074469.issue31430@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Sure, I can certainly do that.

Does "basically a requirement" mean it should have been there all along (with the VC9 installation), or just that trying to use VC9 on a recent system like Win 10 safely requires it installed separately?  I guess Win 8 was the first version to default to only having 4+ already installed.

Oh, any preference between using the OS component setup (windows features) to install vs. downloading an installer?  I was thinking of using the features approach since it's easy to document as a requirement for anyone else.  I doubt there's much difference in the end result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Thu Oct 26 16:27:30 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Oct 2017 20:27:30 +0000
Subject: [issue31803] time.clock() should emit a DeprecationWarning
In-Reply-To: <1509018364.77.0.213398074469.issue31803@psf.upfronthosting.co.za>
Message-ID: <abf66acd-cc36-5243-c356-f2b784e528d5@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 26.10.2017 13:46, Serhiy Storchaka wrote:
> 
> It is very bad, that the function with such attractive name has different meaning on Windows and Unix. I'm sure that virtually all uses of clock() are broken because its behavior on other platform than used by the author of the code.

Not really, no. People who write cross-platform code are well
aware of the differences of time.clock() and people who just
write for one platform know how the libc function of the same
function works on their platform.

Unix: http://man7.org/linux/man-pages/man3/clock.3.html
Windows: https://msdn.microsoft.com/en-us/library/4e2ess30.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31803>
_______________________________________

From report at bugs.python.org  Thu Oct 26 16:40:51 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 26 Oct 2017 20:40:51 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1509050451.71.0.213398074469.issue28936@psf.upfronthosting.co.za>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Is it correct that the parameter can be annotated in the function body?

I agree with Guido, this is rather a task for type checkers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Thu Oct 26 16:51:56 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 26 Oct 2017 20:51:56 +0000
Subject: [issue25729] update pure python datetime.timedelta creation
In-Reply-To: <1448437946.34.0.869547453804.issue25729@psf.upfronthosting.co.za>
Message-ID: <1509051116.4.0.213398074469.issue25729@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Brian, is this still relevant?  If so, cab you submit a pull request?

----------
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25729>
_______________________________________

From report at bugs.python.org  Thu Oct 26 17:28:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 21:28:41 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1509053321.23.0.213398074469.issue28936@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8c83c23fa32405aa9212f028d234f4129d105a23 by Serhiy Storchaka (Ivan Levkivskyi) in branch 'master':
bpo-28936: Detect lexically first syntax error first (#4097)
https://github.com/python/cpython/commit/8c83c23fa32405aa9212f028d234f4129d105a23


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Thu Oct 26 17:29:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Oct 2017 21:29:58 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1509053398.95.0.213398074469.issue28936@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your patch Ivan.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Thu Oct 26 18:17:00 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 22:17:00 +0000
Subject: [issue30989] Sort only when needed in TimedRotatingFileHandler's
 getFilesToDelete
In-Reply-To: <1500707842.79.0.354493990388.issue30989@psf.upfronthosting.co.za>
Message-ID: <1509056220.18.0.213398074469.issue30989@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30989>
_______________________________________

From report at bugs.python.org  Thu Oct 26 18:49:01 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 22:49:01 +0000
Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1509058141.24.0.213398074469.issue24459@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +4106

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24459>
_______________________________________

From report at bugs.python.org  Thu Oct 26 18:51:07 2017
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Oct 2017 22:51:07 +0000
Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1509058267.56.0.213398074469.issue24459@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24459>
_______________________________________

From report at bugs.python.org  Thu Oct 26 20:08:20 2017
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 27 Oct 2017 00:08:20 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1509062900.17.0.213398074469.issue31415@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Does it worth enough?
I didn't think it's worth enough because import will be much slower than one dict lookup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Thu Oct 26 20:20:33 2017
From: report at bugs.python.org (Nick)
Date: Fri, 27 Oct 2017 00:20:33 +0000
Subject: [issue31881] subprocess.returncode not set depending on arguments to
 subprocess.run
Message-ID: <1509063633.12.0.213398074469.issue31881@psf.upfronthosting.co.za>


New submission from Nick <nathompson7 at protonmail.com>:

If subprocess.run is called with a single string, say:

completed_ps = subprocess.run('mpirun -np 4 myexe.x moreargs', shell=True)

and 'myexe.x moreargs' fails with a returncode of 1, then 'completed_ps.returncode' is None. However, if we split the args with shlex, we obtain the desired result, which is a returncode of 1:

import shlex
args = shlex.split('mpirun -np 4 myexe.x moreargs')
completed_ps = subprocess.run(args)
# now completed_ps.returncode = 1 if myexe.x moreargs fails.

Reproduced on Mac, Ubuntu 17.04, Python 3.6.1 and Python 3.6.3.

----------
messages: 305094
nosy: nthompson
priority: normal
severity: normal
status: open
title: subprocess.returncode not set depending on arguments to subprocess.run
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31881>
_______________________________________

From report at bugs.python.org  Thu Oct 26 20:25:09 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Oct 2017 00:25:09 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509063909.05.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +4107
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Thu Oct 26 20:25:10 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Oct 2017 00:25:10 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509063910.56.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch
pull_requests: +4107, 4108
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Thu Oct 26 20:35:23 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Oct 2017 00:35:23 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509064523.44.0.213398074469.issue31858@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I put the new shell variables into PyShell itself.  There is usually only one instance created in a session.

I tested the patch manually in both shell and editor with both the default prompt and with sys.ps1 set before importing idlelib.idle.  Beginning to automate tests for editor and shell is a project in itself.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Thu Oct 26 20:50:46 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Oct 2017 00:50:46 +0000
Subject: [issue31881] subprocess.returncode not set depending on arguments to
 subprocess.run
In-Reply-To: <1509063633.12.0.213398074469.issue31881@psf.upfronthosting.co.za>
Message-ID: <1509065446.44.0.213398074469.issue31881@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you run

  mpirun -np 4 myexe.x moreargs; echo $?

in /bin/sh, what do you see?  You also might try to make sure it is the same mpirun and the same myexe.x that is being called in both cases (it is the mpirun return code you are seeing).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31881>
_______________________________________

From report at bugs.python.org  Thu Oct 26 21:06:53 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Oct 2017 01:06:53 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509066413.63.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +4109
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Thu Oct 26 23:28:32 2017
From: report at bugs.python.org (Nick)
Date: Fri, 27 Oct 2017 03:28:32 +0000
Subject: [issue31881] subprocess.returncode not set depending on arguments to
 subprocess.run
In-Reply-To: <1509063633.12.0.213398074469.issue31881@psf.upfronthosting.co.za>
Message-ID: <1509074912.64.0.213398074469.issue31881@psf.upfronthosting.co.za>


Nick <nathompson7 at protonmail.com> added the comment:

I have verified that

$ mpirun -np 4 myexe.x moreargs; echo $?
1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31881>
_______________________________________

From report at bugs.python.org  Thu Oct 26 23:47:28 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Oct 2017 03:47:28 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509076048.94.0.213398074469.issue31860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks for the patch.  Adding the feature is somehow easier than I expected.  After moving the sample text to module level, which I considered doing before, saving edits for the duration of an IDLE session turned out to also be easy.  

With 11 point Lucida Console, there is room for 5 more lines, without erasing anything, before anything scrolls off the top.

I expect that saving changes across IDLE sessions would be much harder and likely not worth the effort.  I think that exploring font choices is likely rare enough that there is little need to do so.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 00:18:19 2017
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 27 Oct 2017 04:18:19 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1509077899.89.0.213398074469.issue31863@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

A C/C++ program returns EXIT_FAILURE for a generic failure. Microsoft defines this macro value as 1. Most tools that a user might use to forcibly terminate a process don't allow specifying the reason; they just use the generic value of 1. This includes Task Manager, taskkill.exe /f, the WDK's kill.exe -f, and Sysinternals pskill.exe and Process Explorer. subprocess and multiprocessing should also use 1 to be consistent.

The system itself doesn't distinguish a forced termination from a normal exit. Ultimately every thread and process gets terminated by the system calls NtTerminateThread and NtTerminateProcess (or the equivalent Process Manager private functions PspTerminateThreadByPointer, PspTerminateProcess, etc). Windows API TerminateThread and TerminateProcess are light wrappers around the corresponding system calls.

ExitThread and ExitProcess (actually implemented as RtlExitUserThread and RtlExitUserProcess in ntdll.dll) are within-process calls that integrate with the loader's LdrShutdownThread and LdrShutdownProcess routines. This allows the loader to call the entry points for loaded DLLs with DLL_THREAD_DETACH or DLL_PROCESS_DETACH, respectively. ExitThread also handles deallocating the thread's stack. Beyond that, the bulk of the work is handled by NtTerminateThread and NtTerminateProcess. For ExitProcess, NtTerminateProcess is actually called twice -- the first time it's called with a NULL process handle to kill the other threads in the current process. After LdrShutdownProcess returns, NtTerminateProcess is called again to truly terminate the process.

> PowerShell and .NET ... `System.Diagnostics.Process.Kill()` ... 
> `TerminateProcess` is called with -1

.NET is in its own (cross-platform) managed-code universe. I don't know why the developers decided to make Kill() use -1 (0xFFFFFFFF) as the exit code. I can guess that they negated the conventional EXIT_FAILURE value to indicate a signal-like kill. I think it's an odd decision, and I'm not inclined to favor it over behaviors that predate the existence of .NET. 

Making the ExitCode property a signed integer in .NET is easy to understand, and not a cause for concern since it's only a matter of interpretation. Note that the return value from wmain() or wWinMain() is a signed integer. Also, the two fundamental status result types in Windows -- NTSTATUS [1] and HRESULT [2] -- are 32-bit signed integers (warnings and errors are negative). Internally, the NT Process object's EPROCESS structure defines ExitStatus as an NTSTATUS value. You can see in a kernel debugger that it's a 32-bit signed integer (Int4B):

    lkd> dt nt!_eprocess ExitStatus
       +0x624 ExitStatus : Int4B

Python also wants the exit code to be a signed value. If we try to exit with an unsigned value that exceeds 0x7FFF_FFFF, it instead uses a default code of -1 (0xFFFF_FFFF). For example:

    >>> hex(subprocess.call('python -c "raise SystemExit(0x8000_0000)"'))
    '0xffffffff'

Using the corresponding signed integer works fine:

    >>> 0x8000_0000 - 2**32
    -2147483648
    >>> hex(subprocess.call('python -c "raise SystemExit(-2_147_483_648)"'))
    '0x80000000'

[1]: https://msdn.microsoft.com/en-us/library/cc231200
[2]: https://msdn.microsoft.com/en-us/library/cc231198


> termination by a signal "terminates the calling program with 
> exit code 3"

MS C raise() defaults to calling exit(3). I don't know why it uses the value 3; it's a legacy value from the MS-DOS era. Python doesn't directly expose C raise(), so this exit code only occurs in rare circumstances.

Note that SIGINT and SIGBREAK are based on console control events, and in this case the default behavior (i.e. SIG_DFL) is not to call exit(3) but rather to continue to the next registered console control handler. This is normally the Windows default handler (i.e. kernelbase!DefaultHandler), which calls ExitProcess with STATUS_CONTROL_C_EXIT. When closing the console itself (i.e. CTRL_CLOSE_EVENT), if a control handler in a console client returns TRUE, the default handler doesn't get called, but (starting with NT 6.0) the process still has to be terminated. In this case the session server, csrss.exe, calls NtTerminateProcess with STATUS_CONTROL_C_EXIT.

The exit code also isn't normally 3 for SIGABRT when abort() (i.e. os.abort in Python) gets called. In a release build, abort() defaults to using the __fastfail intrinsic (i.e. INT 0x29 on x64 systems) with the code FAST_FAIL_FATAL_APP_EXIT. This terminates the process with a STATUS_STACK_BUFFER_OVERRUN exception. By design, a __fastfail exception cannot be handled. An attached debugger only sees it as a second-chance exception. (Ideally they should have split this functionality into multiple status codes, since a __fastfail isn't necessarily due to a stack buffer overrun.) The error-reporting dialog may change the exit status to 255 in this case, but you can suppress this dialog via SetErrorMode(SEM_NOGPFAULTERRORBOX) or by using a Job object that's flagged to suppress it. You can also override the CRT's default abort() behavior to skip __fastfail. Either set a SIGABRT handler that exits the process. Or call _set_abort_behavior to unset _CALL_REPORTFAULT, in which case the exit code will be 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Fri Oct 27 00:42:18 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 04:42:18 +0000
Subject: [issue31053] Unnecessary argument in command example
In-Reply-To: <1501118256.7.0.957994269182.issue31053@psf.upfronthosting.co.za>
Message-ID: <1509079338.97.0.213398074469.issue31053@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset d609b0c24ebdb748cabcc6c062dfc86f9000e6c4 by Berker Peksag (cocoatomo) in branch 'master':
bpo-31053: Remove redundant 'venv' argument in venv example (GH-2907)
https://github.com/python/cpython/commit/d609b0c24ebdb748cabcc6c062dfc86f9000e6c4


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31053>
_______________________________________

From report at bugs.python.org  Fri Oct 27 00:42:33 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Oct 2017 04:42:33 +0000
Subject: [issue31053] Unnecessary argument in command example
In-Reply-To: <1501118256.7.0.957994269182.issue31053@psf.upfronthosting.co.za>
Message-ID: <1509079353.62.0.213398074469.issue31053@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4110
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31053>
_______________________________________

From report at bugs.python.org  Fri Oct 27 00:47:02 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 04:47:02 +0000
Subject: [issue31053] Unnecessary argument in command example
In-Reply-To: <1501118256.7.0.957994269182.issue31053@psf.upfronthosting.co.za>
Message-ID: <1509079622.77.0.213398074469.issue31053@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 37d1d967eed4018ef397dd9d1515683e5b6b55e7 by Berker Peksag (Miss Islington (bot)) in branch '3.6':
bpo-31053: Remove redundant 'venv' argument in venv example (GH-2907)
https://github.com/python/cpython/commit/37d1d967eed4018ef397dd9d1515683e5b6b55e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31053>
_______________________________________

From report at bugs.python.org  Fri Oct 27 00:47:45 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 04:47:45 +0000
Subject: [issue31053] Unnecessary argument in command example
In-Reply-To: <1501118256.7.0.957994269182.issue31053@psf.upfronthosting.co.za>
Message-ID: <1509079665.22.0.213398074469.issue31053@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31053>
_______________________________________

From report at bugs.python.org  Fri Oct 27 01:57:45 2017
From: report at bugs.python.org (Akos Kiss)
Date: Fri, 27 Oct 2017 05:57:45 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1509083865.12.0.213398074469.issue31863@psf.upfronthosting.co.za>


Akos Kiss <akosthekiss at gmail.com> added the comment:

And I thought that my analysis was thorough... Exit code 1 is the way to go, I agree now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Fri Oct 27 02:51:55 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 27 Oct 2017 06:51:55 +0000
Subject: [issue31877] Build fails on Cygwin since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509087115.11.0.213398074469.issue31877@psf.upfronthosting.co.za>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
title: Build fails on Cython since issue28180 -> Build fails on Cygwin since issue28180

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Fri Oct 27 03:04:35 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 27 Oct 2017 07:04:35 +0000
Subject: [issue30989] Sort only when needed in TimedRotatingFileHandler's
 getFilesToDelete
In-Reply-To: <1500707842.79.0.354493990388.issue30989@psf.upfronthosting.co.za>
Message-ID: <1509087875.56.0.213398074469.issue30989@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset afad147b59fe84b12317f7340ddd2deeecb22321 by Vinay Sajip (Lovesh Harchandani) in branch 'master':
bpo-30989: Sort in TimedRotatingFileHandler only when needed. (GH-2812)
https://github.com/python/cpython/commit/afad147b59fe84b12317f7340ddd2deeecb22321


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30989>
_______________________________________

From report at bugs.python.org  Fri Oct 27 05:46:09 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Oct 2017 09:46:09 +0000
Subject: [issue31877] Build fails on Cygwin since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509097569.69.0.213398074469.issue31877@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 031c4bfadb69feeda82ce886d6b0cadc638d2e1e by Nick Coghlan (Erik Bray) in branch 'master':
bpo-31877: Add _Py_LegacyLocaleDetected and _PyCoerceLegacyLocale to pylifecycle.h (GH-4134)
https://github.com/python/cpython/commit/031c4bfadb69feeda82ce886d6b0cadc638d2e1e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Fri Oct 27 05:46:42 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Oct 2017 09:46:42 +0000
Subject: [issue31877] Build fails on Cygwin since issue28180
In-Reply-To: <1509029699.29.0.213398074469.issue31877@psf.upfronthosting.co.za>
Message-ID: <1509097602.1.0.213398074469.issue31877@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31877>
_______________________________________

From report at bugs.python.org  Fri Oct 27 05:52:53 2017
From: report at bugs.python.org (Davide Rizzo)
Date: Fri, 27 Oct 2017 09:52:53 +0000
Subject: [issue31861] aiter() and anext() built-in functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1509097973.39.0.213398074469.issue31861@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

I attempted to make a Python implementation (attached) to use in my code. There are a few questions in the comments.

One of the complications is the async equivalent of next with two arguments like next(iterator, default). It cannot return the result of __anext__() because it needs to catch StopAsyncIteration. So it should return an awaitable wrapper instead (in my Python code this is rendered as a coroutine). A secondary question is whether the default value should be returned as it is passed, or awaited on.

----------
Added file: https://bugs.python.org/file47242/aiter_comp.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Oct 27 06:02:49 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Oct 2017 10:02:49 +0000
Subject: [issue31878] Cygwin: _socket module does not compile due to missing
 ioctl declaration
In-Reply-To: <1509032541.6.0.213398074469.issue31878@psf.upfronthosting.co.za>
Message-ID: <1509098569.35.0.213398074469.issue31878@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4111

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31878>
_______________________________________

From report at bugs.python.org  Fri Oct 27 06:37:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Oct 2017 10:37:58 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1509100678.48.0.213398074469.issue31415@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I didn't think it's worth enough because import will be much slower than one dict lookup.

I don't care much of performance. For the consistency with other environment variables, I like to only read the environment variable once ("at startup"), and not do it each time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Fri Oct 27 06:41:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Oct 2017 10:41:18 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1509100878.49.0.213398074469.issue31174@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4112

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Fri Oct 27 07:07:58 2017
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 27 Oct 2017 11:07:58 +0000
Subject: [issue31415] Add -X option to show import time
In-Reply-To: <1505107635.07.0.844960422859.issue31415@psf.upfronthosting.co.za>
Message-ID: <1509102478.28.0.213398074469.issue31415@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

Xoptions is not environment variable.

Some modules are imported before xoptions are parsed.
So negative cache for xoptions is little more complex than
negative cache for environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31415>
_______________________________________

From report at bugs.python.org  Fri Oct 27 07:25:21 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 11:25:21 +0000
Subject: [issue31545] Fixing documentation for timedelta.
In-Reply-To: <1506010165.72.0.788430347114.issue31545@psf.upfronthosting.co.za>
Message-ID: <1509103521.84.0.213398074469.issue31545@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 843ea47a034307c7b1ca642dd70f0269255b289a by Berker Peksag (Utkarsh Upadhyay) in branch 'master':
bpo-31545: Update documentation containing timedelta repr. (GH-3687)
https://github.com/python/cpython/commit/843ea47a034307c7b1ca642dd70f0269255b289a


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31545>
_______________________________________

From report at bugs.python.org  Fri Oct 27 07:25:21 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 11:25:21 +0000
Subject: [issue30302] Improve .__repr__ implementation for datetime.timedelta
In-Reply-To: <1494187046.46.0.90330515352.issue30302@psf.upfronthosting.co.za>
Message-ID: <1509103521.95.0.912454111764.issue30302@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 843ea47a034307c7b1ca642dd70f0269255b289a by Berker Peksag (Utkarsh Upadhyay) in branch 'master':
bpo-31545: Update documentation containing timedelta repr. (GH-3687)
https://github.com/python/cpython/commit/843ea47a034307c7b1ca642dd70f0269255b289a


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30302>
_______________________________________

From report at bugs.python.org  Fri Oct 27 07:25:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 11:25:48 +0000
Subject: [issue31545] Fixing documentation for timedelta.
In-Reply-To: <1506010165.72.0.788430347114.issue31545@psf.upfronthosting.co.za>
Message-ID: <1509103548.01.0.213398074469.issue31545@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31545>
_______________________________________

From report at bugs.python.org  Fri Oct 27 07:28:20 2017
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Oct 2017 11:28:20 +0000
Subject: [issue30302] Improve .__repr__ implementation for datetime.timedelta
In-Reply-To: <1494187046.46.0.90330515352.issue30302@psf.upfronthosting.co.za>
Message-ID: <1509103700.77.0.213398074469.issue30302@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

All PRs have been merged in both issues (this and bpo-31545) so I guess this issue can be closed now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30302>
_______________________________________

From report at bugs.python.org  Fri Oct 27 07:47:08 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 27 Oct 2017 11:47:08 +0000
Subject: [issue31872] SSL BIO is broken for internationalized domains
In-Reply-To: <1509012559.64.0.213398074469.issue31872@psf.upfronthosting.co.za>
Message-ID: <1509104828.69.0.213398074469.issue31872@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31872>
_______________________________________

From report at bugs.python.org  Fri Oct 27 08:03:40 2017
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 27 Oct 2017 12:03:40 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509105820.82.0.213398074469.issue18835@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Should we care about the C11 restriction?

http://en.cppreference.com/w/c/memory/aligned_alloc

"size - number of bytes to allocate. An integral multiple of alignment"



posix_memalign and _aligned_malloc don't care about the multiple.

On the other hand, sane requests will have the exact multiple most
of the time anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Fri Oct 27 08:09:34 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 12:09:34 +0000
Subject: [issue16135] Removal of OS/2 support
In-Reply-To: <1349389207.71.0.143036356134.issue16135@psf.upfronthosting.co.za>
Message-ID: <1509106174.86.0.213398074469.issue16135@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
pull_requests: +4113

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16135>
_______________________________________

From report at bugs.python.org  Fri Oct 27 08:27:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Oct 2017 12:27:08 +0000
Subject: [issue16135] Removal of OS/2 support
In-Reply-To: <1349389207.71.0.143036356134.issue16135@psf.upfronthosting.co.za>
Message-ID: <1509107228.87.0.213398074469.issue16135@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 03eb11f0b354751248b427455b89e9340cfd2b47 by Victor Stinner (Erik Bray) in branch 'master':
bpo-16135: Cleanup: Code rot left over from OS/2 support (GH-4147)
https://github.com/python/cpython/commit/03eb11f0b354751248b427455b89e9340cfd2b47


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16135>
_______________________________________

From report at bugs.python.org  Fri Oct 27 08:29:22 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Oct 2017 12:29:22 +0000
Subject: [issue31545] Fixing documentation for timedelta.
In-Reply-To: <1506010165.72.0.788430347114.issue31545@psf.upfronthosting.co.za>
Message-ID: <1509107362.91.0.213398074469.issue31545@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Thank you Utkarsh Upadhyay for finishing the change up to the documentation ;-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31545>
_______________________________________

From report at bugs.python.org  Fri Oct 27 08:35:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Oct 2017 12:35:13 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1509107713.26.0.213398074469.issue31174@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7351f9e5a91c403d15c6d556f9989b443f1296f9 by Serhiy Storchaka in branch 'master':
bpo-31174: Improve the code of test_tools.test_unparse. (#4146)
https://github.com/python/cpython/commit/7351f9e5a91c403d15c6d556f9989b443f1296f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Fri Oct 27 08:35:23 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Oct 2017 12:35:23 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1509107723.3.0.213398074469.issue31174@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4114

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Fri Oct 27 09:08:09 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 13:08:09 +0000
Subject: [issue31882] Cygwin: asyncio and asyncore test suites hang
 indefinitely due to bug in Cygwin
Message-ID: <1509109689.46.0.213398074469.issue31882@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

Some of the tests for asyncio and asyncore block forever on Cygwin, due to a known (and seemingly difficult to fix) bug [1] in Cygwin involving SO_PEERCRED on UNIX sockets.

SO_PEERCRED is a socket option that can be used to exchange file ownership info of the socket at the time the connection was established (specifically on UNIX sockets).  This feature is technically supported on Cygwin, but the effect of the bug is that if two sockets are opened on the same process (even without using socketpair()), the credential exchange protocol can cause connect() on the "client" socket to block unless the "server" socket is already listen()-ing.

This situation is not all that common in practice (it is not a problem if the "client" and "server" are separate processes).  But it does show up in the test suite in a number of places, since both sockets belong to the same process.

I have a patch to work around this and will post a PR shortly.

[1] https://cygwin.com/ml/cygwin/2017-01/msg00054.html

----------
messages: 305118
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31882>
_______________________________________

From report at bugs.python.org  Fri Oct 27 09:12:33 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 13:12:33 +0000
Subject: [issue31882] Cygwin: asyncio and asyncore test suites hang
 indefinitely due to bug in Cygwin
In-Reply-To: <1509109689.46.0.213398074469.issue31882@psf.upfronthosting.co.za>
Message-ID: <1509109953.81.0.213398074469.issue31882@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
keywords: +patch
pull_requests: +4115
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31882>
_______________________________________

From report at bugs.python.org  Fri Oct 27 09:17:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Oct 2017 13:17:38 +0000
Subject: [issue31174] test_tools leaks randomly references on x86 Gentoo
 Refleaks 3.6 and 3.x
In-Reply-To: <1502365539.11.0.343233157276.issue31174@psf.upfronthosting.co.za>
Message-ID: <1509110258.98.0.213398074469.issue31174@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bb78898224c99cbf9c6beed8706869f9b66967c2 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31174: Improve the code of test_tools.test_unparse. (GH-4146) (#4148)
https://github.com/python/cpython/commit/bb78898224c99cbf9c6beed8706869f9b66967c2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31174>
_______________________________________

From report at bugs.python.org  Fri Oct 27 09:42:12 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 13:42:12 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
Message-ID: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

There is an acknowledged bug in Cygwin's implementation of wcsxfrm() [1] that can cause heap corruption in certain cases.  This bug has since been fixed in Cygwin 2.8.1-1 [2] and all current and future releases.  However, that was relatively recent (July 2017) so it may still crop up.

I also have a workaround for this from the Python side, but rather than clutter the code with workarounds for platform-specific bugs I think it suffices just to skip the test in this case.

[1] https://cygwin.com/ml/cygwin/2017-05/msg00149.html
[2] https://cygwin.com/ml/cygwin-announce/2017-07/msg00002.html

----------
messages: 305120
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Cygwin: heap corruption bug in wcsxfrm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Fri Oct 27 09:45:28 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 13:45:28 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509111928.45.0.213398074469.issue31883@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
keywords: +patch
pull_requests: +4116
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Fri Oct 27 10:02:33 2017
From: report at bugs.python.org (Mr JG Kent)
Date: Fri, 27 Oct 2017 14:02:33 +0000
Subject: [issue31884] subprocess set priority on windows
Message-ID: <1509112953.47.0.213398074469.issue31884@psf.upfronthosting.co.za>


Change by Mr JG Kent <james_g_k at hotmail.co.uk>:


----------
components: Library (Lib)
nosy: JamesGKent
priority: normal
severity: normal
status: open
title: subprocess set priority on windows
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31884>
_______________________________________

From report at bugs.python.org  Fri Oct 27 10:06:03 2017
From: report at bugs.python.org (Mr JG Kent)
Date: Fri, 27 Oct 2017 14:06:03 +0000
Subject: [issue31884] subprocess set priority on windows
Message-ID: <1509113163.01.0.213398074469.issue31884@psf.upfronthosting.co.za>


Change by Mr JG Kent <james_g_k at hotmail.co.uk>:


----------
keywords: +patch
pull_requests: +4117
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31884>
_______________________________________

From report at bugs.python.org  Fri Oct 27 10:13:51 2017
From: report at bugs.python.org (Utkarsh Upadhyay)
Date: Fri, 27 Oct 2017 14:13:51 +0000
Subject: [issue31545] Fixing documentation for timedelta.
In-Reply-To: <1506010165.72.0.788430347114.issue31545@psf.upfronthosting.co.za>
Message-ID: <1509113631.88.0.213398074469.issue31545@psf.upfronthosting.co.za>


Utkarsh Upadhyay <musically.ut at gmail.com> added the comment:

:)

There's still a lot of room for improvement on documentation front, esp. the inline __doc__s. I'll be working on that next.

~
ut

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31545>
_______________________________________

From report at bugs.python.org  Fri Oct 27 10:14:48 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Oct 2017 14:14:48 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509113688.71.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

PR 4089 becomes much more larger than what I expected, so I propose to defer enhancements to following PR, especially the idea of "emulating" PyMem_AlignedAlloc() on top of PyMem_Malloc() if the user calls PyMem_SetAllocators() without implemented aligned_alloc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Fri Oct 27 10:56:03 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 14:56:03 +0000
Subject: [issue31885] Cygwin: socket test suites hang indefinitely due to bug
 in Cygwin
Message-ID: <1509116163.97.0.213398074469.issue31885@psf.upfronthosting.co.za>


New submission from Erik Bray <erik.m.bray at gmail.com>:

Like issue31882, this is to mention an upstream bug in Cygwin that causes one of the tests in the test_socket test suite to hang indefinitely.  That bug is fixed upstream [1], but for now it would still be better to skip the test on Cygwin.

The bug is that in some cases a blocking send() (particularly for a large amount data) cannot be interrupted by a signal even if SA_RESTART is not set.

Fixes to this issue, along with issue31882, issue31883, and issue31878 provide the bare minimum for Cygwin to at least compile (not necessarily all optional extension modules) and run the test suite from start to finish (though there may be other tests that cause the interpreter to lock up, but that are currently masked by other bugs).


[1] https://cygwin.com/ml/cygwin-patches/2017-q2/msg00037.html

----------
messages: 305123
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Cygwin: socket test suites hang indefinitely due to bug in Cygwin
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31885>
_______________________________________

From report at bugs.python.org  Fri Oct 27 10:59:26 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 14:59:26 +0000
Subject: [issue31885] Cygwin: socket test suites hang indefinitely due to bug
 in Cygwin
In-Reply-To: <1509116163.97.0.213398074469.issue31885@psf.upfronthosting.co.za>
Message-ID: <1509116366.8.0.213398074469.issue31885@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
keywords: +patch
pull_requests: +4119
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31885>
_______________________________________

From report at bugs.python.org  Fri Oct 27 11:10:27 2017
From: report at bugs.python.org (olarn)
Date: Fri, 27 Oct 2017 15:10:27 +0000
Subject: [issue31886] Multiprocessing.Pool hangs after re-spawning several
 worker process.
Message-ID: <1509117027.21.0.213398074469.issue31886@psf.upfronthosting.co.za>


New submission from olarn <bo.bantukulolarn at gmail.com>:

Multiprocessing's pool apparently attempts to repopulate the pool in an event of sub-process worker crash. However the pool seems to hangs after about ~ 4*(number of worker) process re-spawns.

I've tracked the issue down to queue.get() stalling at multiprocessing.pool, line 102

Is this a known issue? Are there any known workaround?

To reproduce this issue:

import multiprocessing
import multiprocessing.util
import logging

multiprocessing.util._logger = multiprocessing.util.log_to_stderr(logging.DEBUG)
import time
import ctypes


def crash_py_interpreter():
    print("attempting to crash the interpreter in ", multiprocessing.current_process())
    i = ctypes.c_char('a'.encode())
    j = ctypes.pointer(i)
    c = 0
    while True:
        j[c] = 'a'.encode()
        c += 1
    j


def test_fn(x):
    print("test_fn in ", multiprocessing.current_process().name, x)
    exit(0)

    time.sleep(0.1)


if __name__ == '__main__':

    # pool = multiprocessing.Pool(processes=multiprocessing.cpu_count())
    pool = multiprocessing.Pool(processes=1)

    args_queue = [n for n in range(20)]

    # subprocess quits
    pool.map(test_fn, args_queue)

    # subprocess crashes
    # pool.map(test_fn,queue)

----------
components: Library (Lib)
messages: 305124
nosy: olarn
priority: normal
severity: normal
status: open
title: Multiprocessing.Pool hangs after re-spawning several worker process.
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31886>
_______________________________________

From report at bugs.python.org  Fri Oct 27 11:30:00 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 15:30:00 +0000
Subject: [issue4032] distutils doesn't search ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1509118200.04.0.213398074469.issue4032@psf.upfronthosting.co.za>


Change by Erik Bray <erik.m.bray at gmail.com>:


----------
pull_requests: +4120
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 27 12:33:26 2017
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Fri, 27 Oct 2017 16:33:26 +0000
Subject: [issue4032] distutils doesn't search ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1509122006.69.0.213398074469.issue4032@psf.upfronthosting.co.za>


Change by Masayuki Yamamoto <ma3yuki.8mamo10 at gmail.com>:


----------
pull_requests: +4121

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 27 12:50:33 2017
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Fri, 27 Oct 2017 16:50:33 +0000
Subject: [issue4032] distutils doesn't search ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1509123033.02.0.213398074469.issue4032@psf.upfronthosting.co.za>


Masayuki Yamamoto <ma3yuki.8mamo10 at gmail.com> added the comment:

I opened PR 4153 that is an alternative for PR 4136 (issue2445).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 27 12:56:30 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Oct 2017 16:56:30 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509123390.92.0.213398074469.issue31883@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Since this bug has been fixed in Cygwin, I don't think we should add a workaround for it. The expected date of Python 3.7 release is 2018-06-15, this is far from the date of releasing the fixed Cygwin.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Fri Oct 27 13:23:48 2017
From: report at bugs.python.org (Peter Wullinger)
Date: Fri, 27 Oct 2017 17:23:48 +0000
Subject: [issue31887] docs for email.generator are missing a comment on
 special multipart/signed handling
Message-ID: <1509125027.89.0.213398074469.issue31887@psf.upfronthosting.co.za>


New submission from Peter Wullinger <python at dhke.de>:

The documentation for email.generator.{Bytes,}Generator do not mention that Generator._handle_multipart_signed() exists and disables header folding for subparts of multipart/signed.

This may cause some frustration, since, as implemented, rendering a message part enclosed in multipart/signed causes headers to fold differently than rendering the respective message part individually:

>>> text = MIMEText('', 'plain', 'utf-8')
>>> text['X-X'] = 'a b c d e f g h i j k l m n o p q r s t u v w x y z a b c d e f g h i j k l m n o p'
>>> print(text.as_string())
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
X-X: a b c d e f g h i j k l m n o p q r s t u v w x y z a b c d e f g h i j k
 l m n o p


>>> signed = MIMEMultipart('signed', filename='smime.p7s')
>>> signed.attach(text)
>>> print(signed.as_string())
Content-Type: multipart/signed; filename="smime.p7s";
 boundary="===============8046244967080646804=="
MIME-Version: 1.0

--===============8046244967080646804==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
X-X: a b c d e f g h i j k l m n o p q r s t u v w x y z a b c d e f g h i j k l m n o p


--===============8046244967080646804==--

This breaks SMIME signatures when using the partial render to generate the signature. 

A possible workaround is to set maxheaderlen=0 for the partial render, which is the same as what Generator._handle_multipart_signed() does, but to do that one needs to know about the special processing.

Attached is a suggestion at a documentation fix that remedies this problem at least for the online docs.

----------
components: email
files: email-generator-multipart-signed-docs.patch
keywords: patch
messages: 305127
nosy: barry, dhke, r.david.murray
priority: normal
severity: normal
status: open
title: docs for email.generator are missing a comment on special multipart/signed handling
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47243/email-generator-multipart-signed-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31887>
_______________________________________

From report at bugs.python.org  Fri Oct 27 13:33:31 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 27 Oct 2017 17:33:31 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509125611.71.0.213398074469.issue31860@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

I don't know if saving the changes would be too difficult.

1.  Create a new config file for the text (I think it would clutter the existing config files, but could also add it there).
2.  Load font_sample_text from the config file.
3.  In apply(), write the text back to the config file.

Issues:
1.  Have a reset button so that the original sample text could be restored at some point?  If so, then need to store the original (current) text somewherem maybe a .def and .cfg version like for the other settings?  A reset button would also require some screen space from the text frame.

----------
nosy: +csabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 13:52:42 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Oct 2017 17:52:42 +0000
Subject: [issue31871] Support for file descriptor params in os.path
In-Reply-To: <1508995993.41.0.213398074469.issue31871@psf.upfronthosting.co.za>
Message-ID: <1509126761.99.0.213398074469.issue31871@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> support passing file descriptor instead of a path. os.path functions

Are you sure about that?  The docs for os.stat show the dir_fd parameter, used to avoid directory renaming issues or attacks, but it doesn?t say that the *path* argument can be an int file descriptor instead of a str file path.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31871>
_______________________________________

From report at bugs.python.org  Fri Oct 27 13:52:48 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Oct 2017 17:52:48 +0000
Subject: [issue31887] docs for email.generator are missing a comment on
 special multipart/signed handling
In-Reply-To: <1509125027.89.0.213398074469.issue31887@psf.upfronthosting.co.za>
Message-ID: <1509126768.5.0.213398074469.issue31887@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The patch looks good to me if someone wants to make a PR out of it.  If you wouldn't mind digitally signing the CLA, Peter, that would make PSF legal happy, though I doubt a one sentence doc patch is really an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31887>
_______________________________________

From report at bugs.python.org  Fri Oct 27 14:20:03 2017
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Oct 2017 18:20:03 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509128403.3.0.213398074469.issue31883@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

To be clear, are you saying there shouldn't be a workaround to the underlying issue (I agree), or are you saying the test skip shouldn't even be added? I'm in favor of just skipping the test since it's still a problem on (currently) recent Cygwin versions. And it's not a very critical test so I'm happy to just skip it in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Fri Oct 27 15:13:43 2017
From: report at bugs.python.org (Steve Dower)
Date: Fri, 27 Oct 2017 19:13:43 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1509131623.11.0.213398074469.issue31430@psf.upfronthosting.co.za>


Steve Dower <steve.dower at python.org> added the comment:

I don't remember exactly how VS 2008 handled the installation, but it likely wasn't designed with Windows 8 in mind :)

I believe since Windows 8, the Windows Features approach is the correct way to install it, and I'm not even sure you can download installers any more. Certainly the docs [1] do not link anywhere.

1: https://docs.microsoft.com/en-us/dotnet/framework/install/dotnet-35-windows-10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Fri Oct 27 15:15:55 2017
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 27 Oct 2017 19:15:55 +0000
Subject: [issue31884] subprocess set priority on windows
Message-ID: <1509131755.3.0.213398074469.issue31884@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31884>
_______________________________________

From report at bugs.python.org  Fri Oct 27 15:16:05 2017
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 27 Oct 2017 19:16:05 +0000
Subject: [issue31884] subprocess set priority on windows
Message-ID: <1509131765.62.0.213398074469.issue31884@psf.upfronthosting.co.za>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31884>
_______________________________________

From report at bugs.python.org  Fri Oct 27 15:42:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Oct 2017 19:42:06 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509133326.94.0.213398074469.issue31883@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

According to your reference a problem is fixed in recent Cygwin versions, isn't?

Skipping the test on Cygwin means that wcsxfrm() will be untested on this platform. Future regressions will be unnoticed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Fri Oct 27 16:52:24 2017
From: report at bugs.python.org (Ilya Kulakov)
Date: Fri, 27 Oct 2017 20:52:24 +0000
Subject: [issue29890] Constructor of ipaddress.IPv*Interface does not follow
 documentation
In-Reply-To: <1490306388.92.0.69250411121.issue29890@psf.upfronthosting.co.za>
Message-ID: <1509137544.18.0.213398074469.issue29890@psf.upfronthosting.co.za>


Ilya Kulakov <kulakov.ilya at gmail.com> added the comment:

Can this be included into the next bugfix release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29890>
_______________________________________

From report at bugs.python.org  Fri Oct 27 17:18:01 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Oct 2017 21:18:01 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509139080.99.0.213398074469.issue31860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Cheryl, thanks for explaining, in part, why I don't want to do this ;-).  Using the the current .def, .cfg system would mean that the default sample would be frozen.  I want to be able to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 17:19:17 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 27 Oct 2017 21:19:17 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509139157.41.0.213398074469.issue18835@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

>  On the other hand, sane requests will have the exact multiple most of the time anyway.

The ways we've discussed using aligned allocation in numpy wouldn't follow this requirement without special checking. Which isn't necessarily a big deal, and numpy won't necessarily use this API anyway. But I would suggest being very clear about exactly what you guarantee and what you don't :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Fri Oct 27 17:19:53 2017
From: report at bugs.python.org (David Bolen)
Date: Fri, 27 Oct 2017 21:19:53 +0000
Subject: [issue31430] [Windows][2.7] Python 2.7 compilation fails on mt.exe
 crashing with error code C0000005
In-Reply-To: <1505231752.16.0.130246189595.issue31430@psf.upfronthosting.co.za>
Message-ID: <1509139193.27.0.213398074469.issue31430@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Sounds good.  I must admit I hadn't actually gone looking for a standalone installer yet, but just assumed it would exist.

The Win10 worker now has the .NET 3.5 feature installed (which also installed 2.0 and 3.0).  Builds seem fine even after removing the temporary exe config file I had put in place.

So I think we should be good for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31430>
_______________________________________

From report at bugs.python.org  Fri Oct 27 17:24:41 2017
From: report at bugs.python.org (Nick)
Date: Fri, 27 Oct 2017 21:24:41 +0000
Subject: [issue31881] subprocess.returncode not set depending on arguments to
 subprocess.run
In-Reply-To: <1509063633.12.0.213398074469.issue31881@psf.upfronthosting.co.za>
Message-ID: <1509139481.72.0.213398074469.issue31881@psf.upfronthosting.co.za>


Change by Nick <nathompson7 at protonmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31881>
_______________________________________

From report at bugs.python.org  Fri Oct 27 17:28:24 2017
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 27 Oct 2017 21:28:24 +0000
Subject: [issue31863] Inconsistent returncode/exitcode for terminated child
 processes on Windows
In-Reply-To: <1508860013.85.0.213398074469.issue31863@psf.upfronthosting.co.za>
Message-ID: <1509139704.66.0.213398074469.issue31863@psf.upfronthosting.co.za>


Eryk Sun <eryksun at gmail.com> added the comment:

If a multiprocessing Process gets terminated by any means other than its terminate() method, it won't get this special TERMINATE (0x10000) exit code that allows the object to pretend the exit status is POSIX -SIGTERM. In general, the exit code will be 1. IMO, Process.terminate should be consistent with typical exit code of 1 and thus consistent with Popen.terminate. However, I'm adding Davin and Antoine to the nosy list in case they disagree -- before you go to the trouble of creating a PR.

----------
nosy: +davin, pitrou
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31863>
_______________________________________

From report at bugs.python.org  Fri Oct 27 18:09:33 2017
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 Oct 2017 22:09:33 +0000
Subject: [issue18670] Using read_mime_types function from mimetypes module
 gives resource warning
In-Reply-To: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za>
Message-ID: <1509142173.27.0.213398074469.issue18670@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

The patches would mask an OSError raised by the ?readfp? call, which would be a change in behaviour. But moving the call does not seem to be necessary; why not leave it outside the ?try? statement?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18670>
_______________________________________

From report at bugs.python.org  Fri Oct 27 18:16:08 2017
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 Oct 2017 22:16:08 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1509142568.51.0.213398074469.issue24291@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Closing because I understand it is too late to do anything for 3.5 now.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Fri Oct 27 19:25:30 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 27 Oct 2017 23:25:30 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509146730.89.0.213398074469.issue31860@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Makes sense.  I guess I didn't think of it being frozen because I was thinking of it being more like the Recent Files list, but pre-populated if it were empty.  As you said, probably not worth the effort.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 20:09:49 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 Oct 2017 00:09:49 +0000
Subject: [issue26618] _overlapped extension module of asyncio uses deprecated
 WSAStringToAddressA() function
In-Reply-To: <1458729832.02.0.462446337559.issue26618@psf.upfronthosting.co.za>
Message-ID: <1509149389.82.0.213398074469.issue26618@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Unfortunately, Python 3.5 is now in security-fix-only mode. Closing this 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26618>
_______________________________________

From report at bugs.python.org  Fri Oct 27 20:22:52 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 00:22:52 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509150172.31.0.213398074469.issue31860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ed6554c487fb2403bc88be6deee611c7a4171d33 by Terry Jan Reedy (Serhiy Storchaka) in branch 'master':
bpo-31860: Make the font sample in the IDLE font configuration dialog editable. (#4106)
https://github.com/python/cpython/commit/ed6554c487fb2403bc88be6deee611c7a4171d33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 20:22:57 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Oct 2017 00:22:57 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509150177.72.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4122
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 20:37:28 2017
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 Oct 2017 00:37:28 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1509151048.77.0.213398074469.issue2771@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: https://bugs.python.org/msg303087

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Fri Oct 27 20:39:04 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Oct 2017 00:39:04 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509151144.51.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 20:59:40 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 00:59:40 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509152380.59.0.213398074469.issue31860@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6a2957de08e0c2d73f3124d12874b408cda4633d by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6':
bpo-31860: Make the font sample in the IDLE font configuration dialog editable. (GH-4106) (#4154)
https://github.com/python/cpython/commit/6a2957de08e0c2d73f3124d12874b408cda4633d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:01:43 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Oct 2017 01:01:43 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509152503.9.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4124

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:02:32 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:02:32 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509152552.4.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -4123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:03:14 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:03:14 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509152594.4.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:38:37 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:38:37 +0000
Subject: [issue13657] IDLE doesn't recognize resetting sys.ps1.
In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za>
Message-ID: <1509154717.67.0.213398074469.issue13657@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The part about startup files in my last message is probably wrong.  If one starts IDLE by 'import idlelib.idle' after setting 'sys.ps1 = 'me ', then the setting is recognized.  However, a startup file that runs in the user process will not affect sys.ps1 in the IDLE process.  We could add a command line option -p "prompt", but I don't see this as sufficiently important.

At least some shells and consoles recognize special characters in a prompt string to create the prompt.  For instance, the default setting on Windows is "$P$G", which I presume stands for 'working directory path' and 'greater than symbol', with a result such as "F:/dev/3x>".  (I have no idea where this is documented.)  Python and IDLE will print the literal string instead.  Custom prompts therefore seem like an advanced feature, not one aimed at beginners.

----------
title: IDLE doesn't support sys.ps1 and sys.ps2. -> IDLE doesn't recognize resetting sys.ps1.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13657>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:39:39 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Oct 2017 01:39:39 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509154779.34.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:42:43 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:42:43 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509154963.83.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -4109

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:42:52 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:42:52 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509154972.63.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -4108

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:43:38 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:43:38 +0000
Subject: [issue31858] IDLE: cleanup use of sys.ps1 and never set it.
In-Reply-To: <1508824708.42.0.213398074469.issue31858@psf.upfronthosting.co.za>
Message-ID: <1509155018.65.0.213398074469.issue31858@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31858>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:45:21 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 01:45:21 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1509155121.46.0.213398074469.issue31836@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 5a4bbcd479ce86f68bbe12bc8c16e3447f32e13a by Terry Jan Reedy in branch 'master':
bpo-31836: Test_code_module now passes with sys.ps1, ps2 set (#4070)
https://github.com/python/cpython/commit/5a4bbcd479ce86f68bbe12bc8c16e3447f32e13a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Fri Oct 27 21:45:28 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Oct 2017 01:45:28 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1509155128.43.0.213398074469.issue31836@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4126
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sat Oct 28 00:46:37 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Oct 2017 04:46:37 +0000
Subject: [issue31070] test_threaded_import: KeyError ignored in
 _get_module_lock.<locals>.cb
In-Reply-To: <1501254221.02.0.861232217344.issue31070@psf.upfronthosting.co.za>
Message-ID: <1509165997.6.0.213398074469.issue31070@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A recent numpy threaded import bug report that appears in 3.6.1 but is absent in 3.6.3: https://github.com/numpy/numpy/issues/9931

So that's additional evidence that this really was a pre-existing race condition that the new tests for the SystemError cases revealed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31070>
_______________________________________

From report at bugs.python.org  Sat Oct 28 01:40:10 2017
From: report at bugs.python.org (Tilman Krummeck)
Date: Sat, 28 Oct 2017 05:40:10 +0000
Subject: [issue31888] Creating a UUID with a list throws bad exception
Message-ID: <1509169210.77.0.213398074469.issue31888@psf.upfronthosting.co.za>


New submission from Tilman Krummeck <tilman.krummeck at googlemail.com>:

I found a problem by accident on Python 3.5.3 with the uuid library.

Running this:

from uuid import UUID
UUID(["string"])

This throws an AttributeError:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\Tilman Krummeck\AppData\Local\Programs\Python\Python35-32\lib\uuid.py", line 137, in __init__
    hex = hex.replace('urn:', '').replace('uuid:', '')
AttributeError: 'list' object has no attribute 'replace'

This is for sure not intended to work, but should throw a type error in my opinion even before trying to create that UUID object.

----------
components: Library (Lib)
messages: 305148
nosy: TilmanKrummeck
priority: normal
severity: normal
status: open
title: Creating a UUID with a list throws bad exception
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31888>
_______________________________________

From report at bugs.python.org  Sat Oct 28 03:53:22 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 07:53:22 +0000
Subject: [issue31888] Creating a UUID with a list throws bad exception
In-Reply-To: <1509169210.77.0.213398074469.issue31888@psf.upfronthosting.co.za>
Message-ID: <1509177202.44.0.213398074469.issue31888@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a consequence of duck-typing and is common in Python. If you pass a value of wrong type, it is expected that you can get an AttributeError.

Explicit type checks clutter and slow down the code, and make it less flexible.

You can test an explicit type before calling uuid.UUID() in your code if you need.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31888>
_______________________________________

From report at bugs.python.org  Sat Oct 28 04:16:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 08:16:59 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1509178619.78.0.213398074469.issue25612@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Note that removing exc_type, exc_value and exc_traceback from PyThreadState breaks Cython.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Sat Oct 28 04:22:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 08:22:18 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1509178938.36.0.213398074469.issue25612@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The problem I mentioned in msg304117 has been resolved in backward direction: "raise" outside of an except block don't raise a RuntimeError.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Sat Oct 28 05:49:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 09:49:54 +0000
Subject: [issue31871] Support for file descriptor params in os.path
In-Reply-To: <1508995993.41.0.213398074469.issue31871@psf.upfronthosting.co.za>
Message-ID: <1509184194.41.0.213398074469.issue31871@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

?ric, see https://docs.python.org/3/library/os.html#files-and-directories.

Yes, now some os.path functions can accept a file descriptor as a path. I don't think this is intentional. And this may not work on all platforms.

>>> os.path.isdir(1)
False
>>> os.path.islink(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/posixpath.py", line 169, in islink
    st = os.lstat(path)
TypeError: lstat: path should be string, bytes or os.PathLike, not int

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31871>
_______________________________________

From report at bugs.python.org  Sat Oct 28 06:03:33 2017
From: report at bugs.python.org (Simon Descarpentries)
Date: Sat, 28 Oct 2017 10:03:33 +0000
Subject: [issue31889] difflib SequenceMatcher ratio() still have unpredictable
 behavior
Message-ID: <1509185013.27.0.213398074469.issue31889@psf.upfronthosting.co.za>


New submission from Simon Descarpentries <siltaar at acoeuro.com>:

I, it's my 1st post here. I'm a French computer-science engineer with 10 years XP and manager at Acoeuro.com SSLL compagny. I suggested a better regexp integration on python-ideas a few months ago failing to convince getting things done.

Despite issue https://bugs.python.org/issue25391 closed in 2010, nothing seems visible on https://docs.python.org/3/library/difflib.html to help users anticipating that a string greatly matching at 199 characters length, won't at all at the 200th one. It's an inconsistent behavior that looks like a bug.

#!/usr/bin/env python3

from difflib import SequenceMatcher

a = 'ab'*400                                                                                    
b = 'ba'*400

for i in range(1, 400):
    diff_ratio = SequenceMatcher(None, a=a[:i], b=b[:i]).ratio()
    print('%3.i %.2f' % (i, diff_ratio), end=' ')
    not i % 10 and print('')

EOF

At 199c I have a 0.99 ratio, and 0.00 at 200c. The results are nearly the same with strings made of emails like in https://github.com/Siltaar/drop_alternatives especially comparing strings like : 

"performantsetdvelopperducontenusimilairepourvosprochainsTweets.Suiveznous at TwitterBusinesspourdautresinfosetactus.TesterlesPublicitsTwitterbusiness.twitter.com|@TwitterBusiness|Aide|SedsinscrireLemailsadresse at gggTwitter,Inc.MarketStreet,SuiteSanFrancisco,CA"

"rducontenusimilairepourvosprochainsTweets.Suiveznous at TwitterBusinesspourprofiterdautresinfosetactus.TesterlesPublicit?sTwitterbusiness.twitter.com at TwitterBusinessAideSed?sinscrireTwitterInternationalCompanyOneCumberlandPlace,FenianStreetDublin,DAXIRELAND"

Fortunately, I didn't experienced the problem using quick_ratio().

The documentation is not clear about ratio / quick_ratio / real_quick_ratio ; but looks like unstable. With in addition an inconsistent behavior it looks like worthing some fix.

----------
components: Library (Lib)
messages: 305153
nosy: Siltaar
priority: normal
severity: normal
status: open
title: difflib SequenceMatcher ratio() still have unpredictable behavior
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31889>
_______________________________________

From report at bugs.python.org  Sat Oct 28 06:27:51 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Oct 2017 10:27:51 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509186471.36.0.213398074469.issue31626@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sat Oct 28 06:38:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 10:38:37 +0000
Subject: [issue11383] compilation seg faults on insanely large expressions
In-Reply-To: <1299149806.17.0.789738887671.issue11383@psf.upfronthosting.co.za>
Message-ID: <1509187117.8.0.213398074469.issue11383@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If someone will backport an issue5765 patch to 2.7, he can open a new issue or reopen issue5765.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11383>
_______________________________________

From report at bugs.python.org  Sat Oct 28 06:56:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 10:56:13 +0000
Subject: [issue1617161] Instance methods compare equal when their self's are
 equal
Message-ID: <1509188173.63.0.213398074469.issue1617161@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Armin, do you mind to create a pull request on GitHub?

----------
type: enhancement -> behavior
versions: +Python 3.6, Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1617161>
_______________________________________

From report at bugs.python.org  Sat Oct 28 07:25:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 11:25:19 +0000
Subject: [issue16994] collections.Counter.least_common
In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za>
Message-ID: <1509189919.41.0.213398074469.issue16994@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This proposition was discussed also on Python-Ideas (https://mail.python.org/pipermail/python-ideas/2017-March/045215.html).

I think it should be rejected. In general this doesn't make sense. In rare cases when you want to to get the least common items in the Counter (I don't know any practical examples), you can take a list of all items sorted by the value and take few last items.

----------
assignee:  -> rhettinger
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16994>
_______________________________________

From report at bugs.python.org  Sat Oct 28 07:43:20 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 11:43:20 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1509191000.17.0.213398074469.issue31836@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 8ed5644f78e57cd59813097b35906ad6f1775f95 by Terry Jan Reedy (Miss Islington (bot)) in branch '3.6':
bpo-31836: Test_code_module now passes with sys.ps1, ps2 set (GH-4070) (#4156)
https://github.com/python/cpython/commit/8ed5644f78e57cd59813097b35906ad6f1775f95


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sat Oct 28 07:44:06 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 11:44:06 +0000
Subject: [issue31836] test_code_module fails after test_idle
In-Reply-To: <1508601799.24.0.213398074469.issue31836@psf.upfronthosting.co.za>
Message-ID: <1509191046.44.0.213398074469.issue31836@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31836>
_______________________________________

From report at bugs.python.org  Sat Oct 28 07:49:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 11:49:45 +0000
Subject: [issue15606] re.VERBOSE whitespace behavior not completely documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1509191385.3.0.213398074469.issue15606@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Steven, would you mind to update your patch according to review comments and create a pull request on GitHub?

----------
stage: patch review -> needs patch
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15606>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:06:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 12:06:46 +0000
Subject: [issue17418] Documentation links for io.open
In-Reply-To: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>
Message-ID: <1509192406.04.0.213398074469.issue17418@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17418>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:09:10 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 12:09:10 +0000
Subject: [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1509192550.0.0.213398074469.issue22671@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a PR Martin?

----------
assignee: docs at python -> martin.panter
nosy: +serhiy.storchaka
versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:09:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 12:09:57 +0000
Subject: [issue31775] Support unbuffered TextIOWrapper
In-Reply-To: <1507820972.65.0.213398074469.issue31775@psf.upfronthosting.co.za>
Message-ID: <1509192597.07.0.213398074469.issue31775@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31775>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:16:23 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Oct 2017 12:16:23 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1509139157.41.0.213398074469.issue18835@psf.upfronthosting.co.za>
Message-ID: <20171028121612.GA2785@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> The ways we've discussed using aligned allocation in numpy wouldn't follow this requirement without special checking. Which isn't necessarily a big deal, and numpy won't necessarily use this API anyway. But I would suggest being very clear about exactly what you guarantee and what you don't :-).

In the GitHub issue we sort of decided to make the more relaxed Posix
semantics official:

'alignment' must be a power of 2 and a multiple of 'sizeof(void *)'.

'size' can be really anything, so it should work for numpy.

It's a pity that Posix does not round up align={1,2,4} to 'sizeof(void *)'
automatically (why not?), so the applications will have to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:23:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 12:23:16 +0000
Subject: [issue1243730] Big speedup in email message parsing
Message-ID: <1509193396.16.0.213398074469.issue1243730@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1243730>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:27:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 12:27:04 +0000
Subject: [issue18534] State clearly that open() 'file' param is "name" attr of
 the result
In-Reply-To: <1374556018.34.0.468152457131.issue18534@psf.upfronthosting.co.za>
Message-ID: <1509193624.8.0.213398074469.issue18534@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18534>
_______________________________________

From report at bugs.python.org  Sat Oct 28 08:55:22 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 12:55:22 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1509195322.11.0.213398074469.issue31860@psf.upfronthosting.co.za>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -4125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Sat Oct 28 09:30:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 13:30:56 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>
Message-ID: <1509197456.12.0.213398074469.issue20479@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sat Oct 28 10:13:09 2017
From: report at bugs.python.org (=?utf-8?q?Andreas_Kr=C3=BCger?=)
Date: Sat, 28 Oct 2017 14:13:09 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1509199989.2.0.213398074469.issue19891@psf.upfronthosting.co.za>


Andreas Kr?ger <pkydtbegt at famsik.de> added the comment:

I can easily reproduce the problem with Docker,
and it does seem to be a permission problem:

    $ docker run -ti --rm --user="7777:7777" python:3.6.3-jessie bash -c "python3"
    Python 3.6.3 (default, Oct 10 2017, 02:29:16) 
    [GCC 4.9.2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 
    Error in atexit._run_exitfuncs:
    PermissionError: [Errno 13] Permission denied

    $ docker run -ti --rm --user="7777:7777" python:3.6.3-jessie bash -c "HOME=/tmp python3; ls -lta /tmp"
    Python 3.6.3 (default, Oct 10 2017, 02:29:16) 
    [GCC 4.9.2] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 
    total 8
    drwxrwxrwt  2 root root 4096 Oct 28 14:10 .
    drwxr-xr-x 55 root root 4096 Oct 28 14:10 ..
    -rw-------  1 7777 7777    0 Oct 28 14:10 .python_history

----------
nosy: +dj3ei
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19891>
_______________________________________

From report at bugs.python.org  Sat Oct 28 10:26:35 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Oct 2017 14:26:35 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509200795.76.0.213398074469.issue31626@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

> realloc() must not touch the original buffer on failure

I don't understand this: If realloc() fails, the original buffer
is perfectly valid.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sat Oct 28 10:31:29 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Oct 2017 14:31:29 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509201089.15.0.213398074469.issue31626@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Ah sorry, you mean it cannot write the special bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Sat Oct 28 12:00:14 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 16:00:14 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509206414.43.0.213398074469.issue20047@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Oct 28 12:26:52 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 16:26:52 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509208012.35.0.213398074469.issue20047@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4127
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Oct 28 13:06:54 2017
From: report at bugs.python.org (Anselm Kruis)
Date: Sat, 28 Oct 2017 17:06:54 +0000
Subject: [issue31890] Please define the flag METH_STACKLESS for Stackless
 Python
Message-ID: <1509210414.45.0.213398074469.issue31890@psf.upfronthosting.co.za>


New submission from Anselm Kruis <a.kruis at science-computing.de>:

The header Include/methodobject.h defines ml_flags METH_xxx.

Stackless Python adds the flag METH_STACKLESS. Traditionally Stackless used bit 0x0080 for METH_STACKLESS, but starting with C-Python 3.6 bit 0x0080 is used for METH_FASTCALL. 

In order to prevent future conflicts, I propose to add METH_STACKLESS to methodobject.h. 

#ifdef STACKLESS
#define METH_STACKLESS 0x0100
#else
#define METH_STACKLESS 0x0000
#endif

Include/object.h already contains a similar definition.

----------
components: Interpreter Core
messages: 305164
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: Please define the flag METH_STACKLESS for Stackless Python
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31890>
_______________________________________

From report at bugs.python.org  Sat Oct 28 13:16:47 2017
From: report at bugs.python.org (Anselm Kruis)
Date: Sat, 28 Oct 2017 17:16:47 +0000
Subject: [issue31890] Please define the flag METH_STACKLESS for Stackless
 Python
In-Reply-To: <1509210414.45.0.213398074469.issue31890@psf.upfronthosting.co.za>
Message-ID: <1509211007.5.0.213398074469.issue31890@psf.upfronthosting.co.za>


Change by Anselm Kruis <a.kruis at science-computing.de>:


----------
keywords: +patch
pull_requests: +4128
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31890>
_______________________________________

From report at bugs.python.org  Sat Oct 28 13:19:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 17:19:08 +0000
Subject: [issue31890] Please define the flag METH_STACKLESS for Stackless
 Python
In-Reply-To: <1509210414.45.0.213398074469.issue31890@psf.upfronthosting.co.za>
Message-ID: <1509211148.58.0.213398074469.issue31890@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31890>
_______________________________________

From report at bugs.python.org  Sat Oct 28 14:56:50 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 Oct 2017 18:56:50 +0000
Subject: [issue16994] collections.Counter.least_common
In-Reply-To: <1358511873.97.0.161301766615.issue16994@psf.upfronthosting.co.za>
Message-ID: <1509217010.5.0.213398074469.issue16994@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for the suggestion, but I'm going to mark it as rejected for the reasons listed in the other posts.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16994>
_______________________________________

From report at bugs.python.org  Sat Oct 28 16:01:32 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 Oct 2017 20:01:32 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>
Message-ID: <1509220892.08.0.213398074469.issue20479@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

My recommendation is to have *weights* as an optional argument:

    statistics.mean(values, weights=None)

While it is tempting to special case dicts and counters, I got feedback from Jake Vanderplas and Wes McKinney that in practice it is more common to have the weights as a separate list/array/vector.

That API has other advantages as well.  For starters, it is a simple extension of the existing API, so it isn't a disruptive change.  Also, it works well with mapping views: 
   
   statistics.mean(vehicle_sales.keys(), vehicle_sales.values())

And the API also helps support use cases where different weightings are being explored for the same population:

   statistics.mean(salary, years_of_service)
   statistics.mean(salary, education)
   statistics.mean(salary, age)

----------
nosy: +rhettinger
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sat Oct 28 16:23:10 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Oct 2017 20:23:10 +0000
Subject: [issue30696] infinite loop in PyRun_InteractiveLoopFlags()
In-Reply-To: <1497781984.85.0.996199395593.issue30696@psf.upfronthosting.co.za>
Message-ID: <1509222190.1.0.213398074469.issue30696@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +4129
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30696>
_______________________________________

From report at bugs.python.org  Sat Oct 28 16:32:22 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Oct 2017 20:32:22 +0000
Subject: [issue30696] infinite loop in PyRun_InteractiveLoopFlags()
In-Reply-To: <1497781984.85.0.996199395593.issue30696@psf.upfronthosting.co.za>
Message-ID: <1509222742.26.0.213398074469.issue30696@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30696>
_______________________________________

From report at bugs.python.org  Sat Oct 28 16:35:41 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Oct 2017 20:35:41 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509222941.83.0.213398074469.issue20047@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To answer Mark, even though no longer nosy: In general, sequence methods .count, .index, and .__contains__ take sequence members and only members as arguments.  Unicode sequences are exceptional because codepoints are not Python objects, so string subsequences must be used instead.  Byte-like sequences are also exceptional in that both members and subsequences are accepted for these methods.

String-like sequence methods .split and .partition take subsequences as arguments.  I think the doc should make this clearer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Oct 28 17:04:22 2017
From: report at bugs.python.org (Tal Einat)
Date: Sat, 28 Oct 2017 21:04:22 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1509224662.68.0.213398074469.issue20182@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Regarding the select module, the existing patch moves typedefs and object type declarations to the top of the file with the #include clinic/selectmodule.c.h statement can come afterwards. Should I keep it this way, or instead move the method list and type definitions to the bottom of the file, as Serhiy said was preferable with itertoolsmodule.c?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20182>
_______________________________________

From report at bugs.python.org  Sat Oct 28 18:47:25 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 Oct 2017 22:47:25 +0000
Subject: [issue31095] Checking all tp_dealloc with Py_TPFLAGS_HAVE_GC
In-Reply-To: <1501566589.91.0.719711304494.issue31095@psf.upfronthosting.co.za>
Message-ID: <1509230845.48.0.213398074469.issue31095@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

> Should we backport the fix to Python 3.3 and 3.4 as well?
> 
> I don't think so.

I agree with Victor. Closing this as all PRs have been merged. Thank you, all (especially for the documentation update!)

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31095>
_______________________________________

From report at bugs.python.org  Sat Oct 28 19:12:01 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Oct 2017 23:12:01 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509232321.14.0.213398074469.issue20047@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a2314283ff87c65e1745a42c2f2b716b1a209128 by Serhiy Storchaka in branch 'master':
bpo-20047: Make bytearray methods partition() and rpartition() rejecting (#4158)
https://github.com/python/cpython/commit/a2314283ff87c65e1745a42c2f2b716b1a209128


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Oct 28 20:59:29 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Oct 2017 00:59:29 +0000
Subject: [issue28197] range.index mismatch with documentation
In-Reply-To: <1474231832.91.0.157673750963.issue28197@psf.upfronthosting.co.za>
Message-ID: <1509238769.52.0.213398074469.issue28197@psf.upfronthosting.co.za>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28197>
_______________________________________

From report at bugs.python.org  Sat Oct 28 22:23:26 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Oct 2017 02:23:26 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>
Message-ID: <1509243806.14.0.213398074469.issue20479@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thinking back to my signal processing days, I have to agree that our weightings (filter definitions) were usually separate from our data (live signals). Similarly, systems engineering trade studies all maintained feature weights separately from the assessments of the individual options.

The comment from my original RFE about avoiding expanding value -> weight/frequency mappings "to a full iterable all the time" doesn't actually make much sense in 3.x, since m.keys() and m.values() are now typically able to avoid data copying.

So +1 from me for the separates "weights" parameter, with the m.keys()/m.values() idiom used to handle mappings like Counter.

As another point in favour of that approach, it's trivial to build zero-copy weighted variants on top of it for mappings with cheap key and value views:

    def weighted_mean(mapping):
        return statistics.mean(mapping.keys(), mapping.values())

By contrast, if the lowest level primitive provided is a mapping based API, then when you do have separate values-and-weights iterables, you're going to have a much harder time avoiding building a completely new container.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sat Oct 28 22:35:15 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 02:35:15 +0000
Subject: [issue31273] Unicode support in TestCase.skip
In-Reply-To: <1503607033.04.0.29955978966.issue31273@psf.upfronthosting.co.za>
Message-ID: <1509244515.09.0.213398074469.issue31273@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib) -Tests, Unicode
nosy: +michael.foord, rbcollins
stage:  -> needs patch
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31273>
_______________________________________

From report at bugs.python.org  Sat Oct 28 23:06:50 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Oct 2017 03:06:50 +0000
Subject: [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1509246410.43.0.213398074469.issue22671@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

I?m unlikely to soon, but I don?t mind if someone else uses my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Sat Oct 28 23:27:45 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 03:27:45 +0000
Subject: [issue1447222] tkinter Dialog fails when more than four buttons are
 used
Message-ID: <1509247665.84.0.213398074469.issue1447222@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I ported OP's example to Python 3 and I agree with Cheryl that this is fixed now.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed
Added file: https://bugs.python.org/file47244/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1447222>
_______________________________________

From report at bugs.python.org  Sat Oct 28 23:52:06 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 03:52:06 +0000
Subject: [issue30987] Support for ISO-TP protocol in SocketCAN
In-Reply-To: <1500696791.75.0.683510511028.issue30987@psf.upfronthosting.co.za>
Message-ID: <1509249126.54.0.213398074469.issue30987@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

PR 2956 has been merged. Christian, can this issue be closed now?

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30987>
_______________________________________

From report at bugs.python.org  Sun Oct 29 00:00:17 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 04:00:17 +0000
Subject: [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1509249617.88.0.213398074469.issue31065@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +4130
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31065>
_______________________________________

From report at bugs.python.org  Sun Oct 29 00:06:51 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 04:06:51 +0000
Subject: [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1509250011.29.0.213398074469.issue31065@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 0f1973d06e2116deafb19bbb9443b138187803c7 by Berker Peksag in branch '3.6':
bpo-31065: Add doc about Popen.poll returning None. (GH-3169)
https://github.com/python/cpython/commit/0f1973d06e2116deafb19bbb9443b138187803c7


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31065>
_______________________________________

From report at bugs.python.org  Sun Oct 29 00:07:46 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 04:07:46 +0000
Subject: [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1509250066.19.0.213398074469.issue31065@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I've backported 006617ff7d6df3fdedcfe53e94ee2c52cc796437  to 3.6. I think this can be closed now, thank you!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31065>
_______________________________________

From report at bugs.python.org  Sun Oct 29 00:10:02 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Oct 2017 04:10:02 +0000
Subject: [issue31304] Update doc for starmap_async error_back kwarg
In-Reply-To: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>
Message-ID: <1509250202.48.0.213398074469.issue31304@psf.upfronthosting.co.za>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31304>
_______________________________________

From report at bugs.python.org  Sun Oct 29 01:02:59 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Sun, 29 Oct 2017 05:02:59 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509253379.31.0.213398074469.issue18835@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

Given the complexities here, and that the Track/Untrack functions are public now, I do wonder if the actual aligned allocation routines should just be an internal API (i.e., not exposed in Python.h).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Sun Oct 29 04:47:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 08:47:19 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509266839.4.0.213398074469.issue20047@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sun Oct 29 04:47:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 08:47:59 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509266879.82.0.213398074469.issue20047@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4132

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:03:13 2017
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Sun, 29 Oct 2017 09:03:13 +0000
Subject: [issue25720] Fix curses module compilation with ncurses6
In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>
Message-ID: <1509267793.88.0.213398074469.issue25720@psf.upfronthosting.co.za>


Change by Masayuki Yamamoto <ma3yuki.8mamo10 at gmail.com>:


----------
pull_requests: +4133

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25720>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:09:34 2017
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Sun, 29 Oct 2017 09:09:34 +0000
Subject: [issue25720] Fix curses module compilation with ncurses6
In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>
Message-ID: <1509268174.3.0.213398074469.issue25720@psf.upfronthosting.co.za>


Masayuki Yamamoto <ma3yuki.8mamo10 at gmail.com> added the comment:

I opened PR 4164 to improve the is_pad configure check and previous PR was closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25720>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:14:39 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Oct 2017 09:14:39 +0000
Subject: [issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if
 PyRun_InteractiveOneFlags() raises an error
In-Reply-To: <1267793425.09.0.566406511799.issue8070@psf.upfronthosting.co.za>
Message-ID: <1509268479.49.0.213398074469.issue8070@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The infinite loop may occur if one of the functions called by PyRun_InteractiveOneObject() returns persistently -1. This may be the case when there is no more memory and is handled by issue 30696.

It is not possible anymore to reproduce the infinite loop reported in the initial post. See how the 'enc' parameter of PyParser_ASTFromFileObject() is NULL in the following gdb session:

$ gdb -q python -q
Reading symbols from python...done.
(gdb) run
Starting program: /path_to/src/python/master/python
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Python 3.7.0a2+ (heads/master:bdf4298ae2, Oct 29 2017, 09:44:50) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 
Program received signal SIGINT, Interrupt.
0x00007ffff719daa7 in select () from /usr/lib/libc.so.6
(gdb) break PyParser_ASTFromFileObject
Breakpoint 1 at 0x5555555b38d1: file Python/pythonrun.c, line 1181.
(gdb) continue
Continuing.
sys.stdin = None

Breakpoint 1, PyParser_ASTFromFileObject (fp=fp at entry=0x7ffff7461860 <_IO_2_1_stdin_>, 
    filename=filename at entry='<stdin>', enc=enc at entry=0x0, start=start at entry=256, 
    ps1=ps1 at entry=0x7ffff6e7b220 ">>> ", ps2=ps2 at entry=0x7ffff6e7beb8 "... ", 
    flags=0x7fffffffe338, errcode=0x7fffffffe244, arena=0x7ffff6eb2160) at Python/pythonrun.c:1181
1181    {
(gdb) continue
Continuing.
>>> print(chr(0xe9))
?

Breakpoint 1, PyParser_ASTFromFileObject (fp=fp at entry=0x7ffff7461860 <_IO_2_1_stdin_>, 
    filename=filename at entry='<stdin>', enc=enc at entry=0x0, start=start at entry=256, 
    ps1=ps1 at entry=0x7ffff6e7b220 ">>> ", ps2=ps2 at entry=0x7ffff6e7beb8 "... ", 
    flags=0x7fffffffe338, errcode=0x7fffffffe244, arena=0x7ffff6eb2160) at Python/pythonrun.c:1181
1181    {
(gdb) continue
Continuing.
>>> 


Closing as out of date.

----------
nosy: +xdegaye
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8070>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:21:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 09:21:28 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
Message-ID: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

NetBSD perhaps is the last open OS that don't use ncurses. For now the _curses module is not compiled on NetBSD. Its curses implementation doesn't contain several ncurses functions. <term.h> included for non-ncurses implementations defines a couple of macros that conflict with local variable names. The hardcoded signature of setupterm differs from the signature in <term.h>. The fallback implementation of has_key() depends on KEY_* constants that are absent in NetBSD curses too. It seems to me that curses is broken on NetBSD for very long time.

The proposed PR fixes building of the _curses module and makes curses tests passing. This of course doesn't guaranties that curses works correctly on NetBSD, our curses tests are rudimentary.

There were other NetBSD specific guards in the code. They are no longer needed because the guarded functions already are supported in NetBSD for long time. There are issue9667 and issue21457 for removing unneeded conditional compilation.

----------
assignee: serhiy.storchaka
components: Extension Modules
messages: 305180
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make curses compiling on NetBSD 7.1 and tests passing
type: compile error
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:25:18 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 09:25:18 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509269118.78.0.213398074469.issue31891@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4134
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:26:31 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 09:26:31 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509269191.13.0.213398074469.issue31891@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:39:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 09:39:47 +0000
Subject: [issue25720] Fix curses module compilation with ncurses6
In-Reply-To: <1448365148.0.0.732837314732.issue25720@psf.upfronthosting.co.za>
Message-ID: <1509269987.49.0.213398074469.issue25720@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'll try to test this on NetBSD after fixing curses on NetBSD. It uses a different implementation of curses which don't support is_pad.

----------
dependencies: +Make curses compiling on NetBSD 7.1 and tests passing
versions: +Python 2.7, Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25720>
_______________________________________

From report at bugs.python.org  Sun Oct 29 05:59:06 2017
From: report at bugs.python.org (Hanno Boeck)
Date: Sun, 29 Oct 2017 09:59:06 +0000
Subject: [issue31892] ssl.get_server_certificate should allow specifying
 certificate / key type
Message-ID: <1509271146.03.0.213398074469.issue31892@psf.upfronthosting.co.za>


New submission from Hanno Boeck <hanno at hboeck.de>:

The function ssl.get_server_certificate() from the ssl module is supposed to allow fetching the certificate of a TLS server.

However in its current form it provides no way to specify a key type. Many popular hosts (e.g. facebook, google) support both ECDSA and RSA these days, depending on the cipher suites one uses to try to connect to them.

If one wants to fetch the RSA certificate of e.g. facbeook this is not possible with the current python ssl module, as it will always output the ECDSA certificate. One can create a connection with an SSLContext that has only RSA ciphers set, but it's not possible to get the certificate out of an SSLContext. And the get_server_certificate function provides neither a way to bind it to a context nor a way to specify ciphers or key types.

I think there should be an optional parameter to get_server_certificate that allows asking for a specific key type.

----------
assignee: christian.heimes
components: SSL
messages: 305182
nosy: christian.heimes, hanno
priority: normal
severity: normal
status: open
title: ssl.get_server_certificate should allow specifying certificate / key type
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31892>
_______________________________________

From report at bugs.python.org  Sun Oct 29 06:24:50 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 10:24:50 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509272690.51.0.213398074469.issue20047@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9ea5a3a45b35d01b602e7e4da4f72b2db407e5c6 by Serhiy Storchaka in branch '3.6':
[3.6] bpo-20047: Make bytearray methods partition() and rpartition() rejecting (GH-4158) (#4162)
https://github.com/python/cpython/commit/9ea5a3a45b35d01b602e7e4da4f72b2db407e5c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sun Oct 29 06:25:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 10:25:40 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509272740.02.0.213398074469.issue20047@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 107f3cc791d223dc06b7c80f0de672e88ae6a8d1 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-20047: Make bytearray methods partition() and rpartition() rejecting (GH-4158) (#4163)
https://github.com/python/cpython/commit/107f3cc791d223dc06b7c80f0de672e88ae6a8d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sun Oct 29 06:26:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 10:26:39 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1509272799.91.0.213398074469.issue20047@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sun Oct 29 06:59:45 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Oct 2017 10:59:45 +0000
Subject: [issue31886] Multiprocessing.Pool hangs after re-spawning several
 worker process.
In-Reply-To: <1509117027.21.0.213398074469.issue31886@psf.upfronthosting.co.za>
Message-ID: <1509274785.45.0.213398074469.issue31886@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Generally speaking, queues can remain in an inconsistent state after a process crash (because the process might have crashed just after acquiring a shared semaphore or sending part of a large message).  It's not obvious to me how we could make them safer, at least under Unix where there's no widely-available message-oriented communication facility that I know of.

----------
nosy: +davin, pitrou
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31886>
_______________________________________

From report at bugs.python.org  Sun Oct 29 07:02:09 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Oct 2017 11:02:09 +0000
Subject: [issue31886] Multiprocessing.Pool hangs after re-spawning several
 worker process.
In-Reply-To: <1509117027.21.0.213398074469.issue31886@psf.upfronthosting.co.za>
Message-ID: <1509274929.72.0.213398074469.issue31886@psf.upfronthosting.co.za>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +Olivier.Grisel, tomMoral

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31886>
_______________________________________

From report at bugs.python.org  Sun Oct 29 07:23:36 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Oct 2017 11:23:36 +0000
Subject: [issue31749] Request: Human readable byte amounts in the standard
 library
In-Reply-To: <1507655453.9.0.213398074469.issue31749@psf.upfronthosting.co.za>
Message-ID: <1509276216.99.0.213398074469.issue31749@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Ken Kundert started a related discussion a while back on Python-ideas: <https://www.mail-archive.com/search?l=mid&q=20160830203427.GE2363 at kundert.designers-guide.com>. This was about SI-prefixed units in general; not restricted to bytes. Also, the ?timeit? module already does auto-scaling across nsec, usec, msec, and sec.

I think supporting decimal SI prefixes (for ?s, mL, km, MW, etc) is more important than the binary versions (KiB, MiB, GiB). And units of 1,024,000 are definitely too niche.

I think a new format type ?:h? may be the way forward. Perhaps it would add an SI prefix, and then the user could append their unit:

>>> f"{123901842:h}B"  # Six significant digits by default (like ?:g?)
"123.902 MB"
>>> f"{123901842:.5h}B"  # Drop trailing zeros
"123.9 MB"
>>> f"{12:+6h}m"  # Sign and width options may be useful
"  +12 m"
>>> f"{12e99:h}m"  # Exponential notation for extreme values
"1.2e100 m"
>>> f"{12e99:H}m"  # Capitalize E, INF, etc (but not k for kilo-, etc)
"1.2E100 m"
>>> f"{123901:#.5h}m"  # Alternative form keeps trailing zeros
"123.90 km"
>>> f"{123:.2h}m"  # Precision < 3 may not be respected
"123 m"
>>> f"{123:#.2h}m"  # Maybe alternative form could respect the precision
"0.12 km"
>>> f"{123901842:.4h}B".replace(" ", "")  # Avoid the space
"123.9MB"
>>> f"{123901842:.4h}B".replace(" ", "&nbsp;")  # Alternative space
"123.9&nbsp;MB"
>>> f"{123901842:.4h}B".replace(".", ",")  # Alternative to decimal point
"123,9 MB"
>>> f"{12e-6:h}sec"  # Non-ASCII by default
"12 ?sec"
>>> f"{12e-6:h}sec".replace("\N{MICRO SIGN}", "u")  # ASCII compatibility
"12 usec"

Squares and cubes may be a minor stumbling block: 0.001?m? is one thousand square millimetres, but f"{0.001:.3h}m?" would return "1 mm?".

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31749>
_______________________________________

From report at bugs.python.org  Sun Oct 29 07:44:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 11:44:41 +0000
Subject: [issue31893] Issues with kqueue
Message-ID: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

In Modules/selectmodule.c it is assumed that the kevent structure is defined on FreeBSD and NetBSD as:

     struct kevent {
             uintptr_t ident;
             short     filter;
             u_short   flags;
             u_int     fflags;
             intptr_t  data;
             uintptr_t udata;
     };

and on OpenBSD as:

     struct kevent {
             u_int     ident;
             short     filter;
             u_short   flags;
             u_int     fflags;
             intptr_t  data;
             int       udata;
     };


Actually it is defined on FreeBSD as:

     struct kevent {
             uintptr_t ident;
             short     filter;
             u_short   flags;
             u_int     fflags;
             intptr_t  data;
             void      *udata;
     };

On OpenBSD as:

     struct kevent {
             uintptr_t ident;
             short     filter;
             u_short   flags;
             u_int     fflags;
             int64_t   data;
             void      *udata;
     };

And on NetBSD as:

     struct kevent {
             uintptr_t ident;
             uint32_t  filter;
             uint32_t  flags;
             uint32_t  fflags;
             int64_t   data;
             intptr_t  udata;
     };

Other issues are related to rich comparison. Due to integer overflows the ordering is not transitive. The rich comparison protocol is not properly supported, comparing a kevent_event object with a non-kevent_event object don't falls back to the rich comparison methods of the right arguments.

----------
assignee: serhiy.storchaka
components: Extension Modules, FreeBSD
messages: 305187
nosy: koobs, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Issues with kqueue
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Sun Oct 29 07:52:58 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 11:52:58 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509277978.29.0.213398074469.issue31893@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4135
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Sun Oct 29 13:45:08 2017
From: report at bugs.python.org (Cornelius Diekmann)
Date: Sun, 29 Oct 2017 17:45:08 +0000
Subject: [issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x
In-Reply-To: <1453953861.58.0.104331734212.issue26228@psf.upfronthosting.co.za>
Message-ID: <1509299108.05.0.213398074469.issue26228@psf.upfronthosting.co.za>


Change by Cornelius Diekmann <c.diekmann at googlemail.com>:


----------
pull_requests: +4136

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26228>
_______________________________________

From report at bugs.python.org  Sun Oct 29 14:33:02 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Oct 2017 18:33:02 +0000
Subject: [issue31304] Update doc for starmap_async error_back kwarg
In-Reply-To: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>
Message-ID: <1509301982.71.0.213398074469.issue31304@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +4137
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31304>
_______________________________________

From report at bugs.python.org  Sun Oct 29 15:30:40 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 19:30:40 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509305440.97.0.213398074469.issue31630@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is the same result on NetBSD 7.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct 29 16:12:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 20:12:55 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509307975.51.0.213398074469.issue31630@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4138
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct 29 16:13:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 20:13:57 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509308037.05.0.213398074469.issue31630@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Tests -Extension Modules
title: math.tan has poor accuracy near pi/2 on OpenBSD -> math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD
versions: +Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct 29 16:18:19 2017
From: report at bugs.python.org (Tim Peters)
Date: Sun, 29 Oct 2017 20:18:19 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509308299.87.0.213398074469.issue31630@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

BTW, has anyone tried running a tiny C program on these platforms to see what tan(1.5707963267948961) delivers?  The kind of code fdlibm uses is sensitive not only to compiler (mis)optimization, but also to stuff like how the FPU's "precision control" is set, and to whether fused multiply-add is being used, and ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct 29 16:22:33 2017
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 Oct 2017 20:22:33 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1509308299.87.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <20171029202221.GA22547@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Also, does this occur in a VM on on the bare metal or both?

What leaves me puzzled is that I cannot reproduce the Linux x86 report
with almost the exact same compiler. But I'm on x64 and use -m32.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct 29 16:58:34 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 20:58:34 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509310714.69.0.213398074469.issue31630@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have got both (!) results in the same binary on NetBSD (gcc 4.8.5).

tan(1.57079632679489611) = 1978937966095219.000000
tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50
tan(1.57079632679489611) = 1978945885716843.000000
tan(0x1.921fb54442d16p+0) = 0x1.c1f5cfa3105acp+50

Seems the first result is calculated at compile time while the second result is calculated at run time.

On OpenBSD (gcc 4.2.1):

tan(1.57079632679489611) = 1978945885716843.000000
tan(0x1.921fb54442d16p+0) = 0x1.c1f5cfa3105acp+50
tan(1.57079632679489611) = 1978945885716843.000000
tan(0x1.921fb54442d16p+0) = 0x1.c1f5cfa3105acp+50

On Linux (gcc 7.2.0) and FreeBSD (clang 4.0.0):

tan(1.57079632679489611) = 1978937966095219.000000
tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50
tan(1.57079632679489611) = 1978937966095219.000000
tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50

----------
Added file: https://bugs.python.org/file47245/tan_pi2.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Sun Oct 29 17:10:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 21:10:45 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
Message-ID: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

$ ./python -m test -vuall test_datetime
...
======================================================================
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython3.7/Lib/test/support/__init__.py", line 1622, in inner
    return func(*args, **kwds)
  File "/home/serhiy/py/cpython3.7/Lib/test/datetimetester.py", line 1977, in test_timestamp_naive
    self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0


...

Simple reproducer:

$ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import datetime; print(datetime.datetime(1970, 1, 1).timestamp())'
14400.0

It should print 18000.0 (5 hours) instead of 14400.0 (4 hours).

----------
components: Library (Lib), Tests
messages: 305192
nosy: belopolsky, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_timestamp_naive failed on NetBSD
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 17:58:37 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Oct 2017 21:58:37 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <1509314317.21.0.213398074469.issue31894@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I don't have access to NetBSD and this looks like a bug in the system implementation of localtime.  The timestamp method is implemented by probing system localtime in the vicinity of UTC timestamp.

What does time.localtime(14400) with these TZ settings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 18:09:53 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 22:09:53 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <1509314993.32.0.213398074469.issue31894@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

$ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import time; print(time.localtime(14400))'
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 18:13:26 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Oct 2017 22:13:26 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <1509315206.04.0.213398074469.issue31894@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I hate this long form display!

Next time please use time.localtime(14400)[:].

Do you agree that this is a system bug?  On my Mac, I get

$ python -c 'import time; print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2, 365, 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 18:15:55 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Oct 2017 22:15:55 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <1509315355.83.0.213398074469.issue31894@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I posted a wrong command, but fortunately I am in New York, so it did not matter

$ TZ=EST+05EDT,M3.2.0,M11.1.0 python -c 'import time;print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2, 365, 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 18:42:22 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Oct 2017 22:42:22 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <1509316942.4.0.213398074469.issue31894@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not a datetime expert. What is the better way to skip the test? Is it worth to change the date to say (1970, 3, 9) for which the correct result is obtained on this system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 19:25:06 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Oct 2017 23:25:06 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509316942.4.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <CAP7h-xb9twhFY1eNN3fGHYCmkPUTy_7sf2MOp9BRcQh1L__s_A@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am not sure.  This is a system bug and we often provide work-arounds
or even reimplementations of buggy time functions in the time and
datetime modules. Whether or not this is something that is worth
fixing is a question for the affected NetBSD users.

I would say, for the purposes of this issue - add a skip for NetBSD to
the failing test and add a test for another date that can be included
on all systems.

If motivated, please open a separate issue for the time.localtime() bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 20:57:42 2017
From: report at bugs.python.org (Haneef)
Date: Mon, 30 Oct 2017 00:57:42 +0000
Subject: [issue31895] Native hijri calendar support
Message-ID: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>


New submission from Haneef <haneef95 at gmail.com>:

There should be native support for converting between Hijri (Umm al-Qura), Gregorian, Julian and UnixTime calendars.

Many big players have included native support for Hijri calendar in their SDKs and software. Below are some:

(Java Hijri calendar support)[https://docs.oracle.com/javase/8/docs/api/java/time/chrono/HijrahChronology.html]
(Apple supports the Hijri calendar in 5 of their SDKs (Software Development Kits))[https://developer.apple.com/documentation/foundation/calendar.identifier]
(Microsoft Windows supports Hijri calendar naively)[https://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx]
(Microsoft Office has native support)[https://blogs.technet.microsoft.com/office_global_experience/2010/01/13/um-al-qura-calendar-support-in-office-2010/]
(Android Hijri calendar support)[https://developer.android.com/reference/android/icu/util/IslamicCalendar.html]
(Google Calendar allows Hijri calendar as an alternate calendar)[https://www.maketecheasier.com/display-alternate-calendar-google-calendar/]

----------
messages: 305199
nosy: haneef95
priority: normal
severity: normal
status: open
title: Native hijri calendar support
type: enhancement
versions: Python 2.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Sun Oct 29 21:00:42 2017
From: report at bugs.python.org (Haneef)
Date: Mon, 30 Oct 2017 01:00:42 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509325242.21.0.213398074469.issue31895@psf.upfronthosting.co.za>


Haneef <haneef95 at gmail.com> added the comment:

This feature can be added to the (datetime.py)[https://docs.python.org/3/library/datetime.html], Java has done a similar move and it makes the whole process a lot easier.

The Hijri calendar is used across the globe by various websites and developers, some have even made libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Sun Oct 29 21:30:03 2017
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Oct 2017 01:30:03 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509311445.47.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <1509327003.95.0.213398074469.issue31894@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

Are you sure it is a ?system? bug? As far as I understand, at least Posix does not require support for local time before 1970. See <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16>.

But why is localtime(14400) relevant? The documentation only says ?datetime.timestamp? calls ?mktime?, which should be valid since the UTC-5 timezone offset will give a positive timestamp. Perhaps is this similar to Issue 29097, probing a date before 1970?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 21:54:52 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 30 Oct 2017 01:54:52 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509328492.84.0.213398074469.issue31895@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Python 2.7 is in feature freeze, so 3.7 is the absolute earliest this could be introduced. Given how close we are to 3.7 feature freeze, 3.8 is more likely.

I don't think we would have any objections to supporting hijri calendar, in principle, but as a practical matter I expect that none of the core developers are probably qualified to write, review, support and maintain it. (I could be wrong, of course.) And what interface is required?

I'm not convinced that the datetime module is the right place for this. In the long run, we should expect that Python may support multiple calendars: Western, Arabic, Jewish, Asian calendars, and more. I think that would make datetime too big and clunky.

I think the best approach would be to provide a third-party package on PyPI, and once it has proven itself, it could be proposed for the standard library.

----------
nosy: +steven.daprano
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Sun Oct 29 21:54:59 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 30 Oct 2017 01:54:59 +0000
Subject: [issue31894] test_timestamp_naive failed on NetBSD
In-Reply-To: <1509327003.95.0.213398074469.issue31894@psf.upfronthosting.co.za>
Message-ID: <CAP7h-xZ0Hks_6zejGhZt-FMgf2J1kpqhawWOhwMtu9aq3y_kPA@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

> The documentation only says ?datetime.timestamp? calls ?mktime?

Indeed.  See <https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp>.

This is a documentation bug.  Since 3.6 the timestamp does not call
mktime.  In fact, mktime should not be called anywhere in the datetime
module. See <https://github.com/python/cpython/blob/a2314283ff87c65e1745a42c2f2b716b1a209128/Modules/_datetimemodule.c#L5315>.

For the explanation of why mktime is not a good API, see PEP 495.

On Sun, Oct 29, 2017 at 9:30 PM, Martin Panter <report at bugs.python.org> wrote:
>
> Martin Panter <vadmium+py at gmail.com> added the comment:
>
> Are you sure it is a ?system? bug? As far as I understand, at least Posix does not require support for local time before 1970. See <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16>.
>
> But why is localtime(14400) relevant? The documentation only says ?datetime.timestamp? calls ?mktime?, which should be valid since the UTC-5 timezone offset will give a positive timestamp. Perhaps is this similar to Issue 29097, probing a date before 1970?
>
> ----------
> nosy: +martin.panter
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31894>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31894>
_______________________________________

From report at bugs.python.org  Sun Oct 29 23:53:39 2017
From: report at bugs.python.org (Yang Big)
Date: Mon, 30 Oct 2017 03:53:39 +0000
Subject: [issue31896] In function define class inherit ctypes.structure,
 and using ctypes.pointer leak memory
Message-ID: <1509335619.79.0.213398074469.issue31896@psf.upfronthosting.co.za>


New submission from Yang Big <qq519476132 at gmail.com>:

Here my code:
  2 import sys
  3 import ctypes
  4      
  5      
  6 def hi():
  7     class timespec(ctypes.Structure):
  8     ?   """Time specification, as described in clock_gettime(3)."""
  9     ?   _fields_ = (('tv_sec', ctypes.c_long),
 10     ?   ?   ?   ?   ('tv_nsec', ctypes.c_long))
 11      
 12      
 13     ts = timespec()
 14     po = ctypes.pointer(ts)
 15      
 16      
 17 def main():
 18     while True:
 19     ?   test = hi()
 20      
 21 if __name__ == "__main__":
 22     sys  2 import sys
  3 import ctypes
  4      
  5      
  6 def hi():
  7     class timespec(ctypes.Structure):
  8     ?   """Time specification, as described in clock_gettime(3)."""
  9     ?   _fields_ = (('tv_sec', ctypes.c_long),
 10     ?   ?   ?   ?   ('tv_nsec', ctypes.c_long))
 11      
 12      
 13     ts = timespec()
 14     po = ctypes.pointer(ts)
 15      
 16      
 17 def main():
 18     while True:
 19     ?   test = hi()
 20      
 21 if __name__ == "__main__":
 22     sys.exit(main())

run this code, i find that the program occupy more and more VmRss
my python is 2.7.11, in python3 i also find this problem. 
   Is this normal?I am a newbie with python, not very familiar with some 
python's internal principle. 
   Tanks.

----------
components: ctypes
messages: 305204
nosy: Yang Big, amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
status: open
title: In function define class inherit ctypes.structure, and using ctypes.pointer leak memory
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31896>
_______________________________________

From report at bugs.python.org  Mon Oct 30 00:04:14 2017
From: report at bugs.python.org (Ned Williamson)
Date: Mon, 30 Oct 2017 04:04:14 +0000
Subject: [issue31897] RecursionError in plistlib.loads
Message-ID: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>


New submission from Ned Williamson <nedwilliamson at gmail.com>:

Hi,

The following program crashes for me using the current Python3.7 master:

```
import plistlib
plistlib.loads(b'\xdd\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
               b'\xda\x0cw\xb7\x00\x00\x00\x00\x00\x00\x00\xc7\x00'
               b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\xd6\xd5\x00'
               b'\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00'
               b'\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00',
               fmt=plistlib.FMT_BINARY)
```

The last few lines look like
```
  File "/usr/lib/python3.5/plistlib.py", line 728, in _read_object
    ] = self._read_object(self._object_offsets[o])
  File "/usr/lib/python3.5/plistlib.py", line 728, in _read_object
    ] = self._read_object(self._object_offsets[o])
  File "/usr/lib/python3.5/plistlib.py", line 723, in _read_object
    key_refs = self._read_refs(s)
  File "/usr/lib/python3.5/plistlib.py", line 647, in _read_refs
    return self._read_ints(n, self._ref_size)
  File "/usr/lib/python3.5/plistlib.py", line 644, in _read_ints
    for i in range(0, size * n, size))
RecursionError: maximum recursion depth exceeded in comparison
```

This bug was found using an alpha version of python-fuzz.

----------
messages: 305205
nosy: Ned Williamson
priority: normal
severity: normal
status: open
title: RecursionError in plistlib.loads
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 00:06:06 2017
From: report at bugs.python.org (Ned Williamson)
Date: Mon, 30 Oct 2017 04:06:06 +0000
Subject: [issue31897] RecursionError in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509336366.56.0.213398074469.issue31897@psf.upfronthosting.co.za>


Ned Williamson <nedwilliamson at gmail.com> added the comment:

The crashing version numbers are from testing on the release Python 3.5, but I think we can just fix this in 3.7+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 00:16:44 2017
From: report at bugs.python.org (Ned Williamson)
Date: Mon, 30 Oct 2017 04:16:44 +0000
Subject: [issue31897] RecursionError in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509337004.82.0.213398074469.issue31897@psf.upfronthosting.co.za>


Ned Williamson <nedwilliamson at gmail.com> added the comment:

I'm filing related bugs under this same issue.

```
import plistlib
dat = b'Q\xe4\xfeAIAAAAAAAAwAAA\xc9A\xc1AAA\xc1AAAAAAA\x9cAAAAAAAAAAAAAAnAAA\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AA'
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
```
raises

```
Traceback (most recent call last):
  File "repro.py", line 3, in <module>
    plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
  File "/usr/lib/python3.5/plistlib.py", line 1006, in loads
    fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/usr/lib/python3.5/plistlib.py", line 997, in load
    return p.parse(fp)
  File "/usr/lib/python3.5/plistlib.py", line 623, in parse
    return self._read_object(self._object_offsets[top_object])
  File "/usr/lib/python3.5/plistlib.py", line 699, in _read_object
    result =  self._fp.read(s).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in range(128)
```

It seems only `InvalidFileException` should be raised by this function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 00:19:11 2017
From: report at bugs.python.org (Ned Williamson)
Date: Mon, 30 Oct 2017 04:19:11 +0000
Subject: [issue31897] RecursionError in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509337151.06.0.213398074469.issue31897@psf.upfronthosting.co.za>


Ned Williamson <nedwilliamson at gmail.com> added the comment:

```
import plistlib
dat = b'AAAAAAAAAAAwAAA\xc9AAAAAAAAAAAAA\x9cAAAAAAAAAAAAAAAAAA\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00AAAAA\x04\xb2\xaaAAAAAA'
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
```
raises
```
Traceback (most recent call last):
  File "repro.py", line 3, in <module>
    plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
  File "/usr/lib/python3.5/plistlib.py", line 1006, in loads
    fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/usr/lib/python3.5/plistlib.py", line 997, in load
    return p.parse(fp)
  File "/usr/lib/python3.5/plistlib.py", line 621, in parse
    self._fp.seek(offset_table_offset)
OverflowError: Python int too large to convert to C ssize_t
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 00:24:28 2017
From: report at bugs.python.org (Ned Williamson)
Date: Mon, 30 Oct 2017 04:24:28 +0000
Subject: [issue31897] RecursionError in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509337468.43.0.213398074469.issue31897@psf.upfronthosting.co.za>


Ned Williamson <nedwilliamson at gmail.com> added the comment:

```
import plistlib
dat = b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AAAnAAA'
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
```
raises
```
Traceback (most recent call last):
  File "repro.py", line 3, in <module>
    plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
  File "/usr/lib/python3.5/plistlib.py", line 1006, in loads
    fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/usr/lib/python3.5/plistlib.py", line 997, in load
    return p.parse(fp)
  File "/usr/lib/python3.5/plistlib.py", line 622, in parse
    self._object_offsets = self._read_ints(num_objects, offset_size)
  File "/usr/lib/python3.5/plistlib.py", line 644, in _read_ints
    for i in range(0, size * n, size))
ValueError: range() arg 3 must not be zero
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 01:17:27 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Oct 2017 05:17:27 +0000
Subject: [issue31898] Add `recommended-packages.txt` to `venv` documentation
Message-ID: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As per the python-ideas thread starting at https://mail.python.org/pipermail/python-ideas/2017-October/047508.html, this is proposal to add a `pip -r` compatible `recommended-packages.txt` file to the `venv` documentation that summarises replacement module recommendations in other parts of the standard library documentation.

Suggested entries are:

requests    # Recommendation in urllib.request docs
regex       # Recommendation in re docs
cffi        # More typesafe alternative to ctypes
six         # Python 2/3 compatibility library
setuptools  # Alternative to distutils that supports modern packaging standards

I'm also tempted to suggest pytz as the preferred source of up-to-date named timezones, but I'm not sure how often that's really needed in situations where you can't just depend on it explicitly instead.

----------
assignee: ncoghlan
components: Documentation
messages: 305210
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add `recommended-packages.txt` to `venv` documentation
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31898>
_______________________________________

From report at bugs.python.org  Mon Oct 30 01:19:09 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Oct 2017 05:19:09 +0000
Subject: [issue31898] Add `recommended-packages.txt` to `venv` documentation
In-Reply-To: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>
Message-ID: <1509340749.36.0.213398074469.issue31898@psf.upfronthosting.co.za>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31898>
_______________________________________

From report at bugs.python.org  Mon Oct 30 01:23:17 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Oct 2017 05:23:17 +0000
Subject: [issue31899] Ensure backwards compatibility with recommended packages
Message-ID: <1509340997.49.0.213398074469.issue31899@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

This is a potential follow-up to issue 31898, whereby the recommended packages list could be taken into account as part of CPython's own testing regime. The gist of the idea would be to:

1. Update the recommended-packages list to nominate particular *versions* of those dependencies (the latest available version as of each CPython maintenance release)
2. Add a new "-uthird-party" resource definition to the regression test suite
3. Add a new regression test that installed the recommended packages into a virtual environment and ran their tests when that resource was enabled


It's a separate issue, since this would be more work to maintain than the simple "we recommend these packages" list proposed in issue 31898.

----------
assignee: ncoghlan
components: Tests
messages: 305211
nosy: ncoghlan
priority: low
severity: normal
stage: test needed
status: open
title: Ensure backwards compatibility with recommended packages
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31899>
_______________________________________

From report at bugs.python.org  Mon Oct 30 01:24:26 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Oct 2017 05:24:26 +0000
Subject: [issue31898] Add `recommended-packages.txt` to `venv` documentation
In-Reply-To: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>
Message-ID: <1509341066.85.0.213398074469.issue31898@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

https://bugs.python.org/issue31899 is a follow-up issue to discuss whether or not it would make sense to expand these recommendations to cover explicit compatibility testing against these libraries for CPython updates

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31898>
_______________________________________

From report at bugs.python.org  Mon Oct 30 03:02:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 07:02:48 +0000
Subject: [issue31897] RecursionError in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509346968.03.0.213398074469.issue31897@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report Ned. But there are no crashes. The term crash means a segmentation fault or similar error that causes the interpreter to exit immediately.

----------
assignee:  -> serhiy.storchaka
components: +Library (Lib)
nosy: +serhiy.storchaka
type: crash -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 03:03:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 07:03:45 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509347025.06.0.213398074469.issue31897@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: RecursionError in plistlib.loads -> Unexpected exceptions in plistlib.loads

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 04:23:56 2017
From: report at bugs.python.org (Tal Einat)
Date: Mon, 30 Oct 2017 08:23:56 +0000
Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za>
Message-ID: <1509351836.81.0.213398074469.issue20180@psf.upfronthosting.co.za>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +4139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20180>
_______________________________________

From report at bugs.python.org  Mon Oct 30 04:37:32 2017
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 30 Oct 2017 08:37:32 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509352652.53.0.213398074469.issue31895@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

It is a substantial undertaking, requiring a great deal of expertise, to implement the Islamic calendar. The difficulty is that there are multiple versions of the calendar. In some places the calendar is based on human observation of the new moon, and so a database of past observations is needed (and future dates can't be represented). In other places the time of observability of the new moon is calculated according to an astronomical ephemeris (and different ephemerides are used in different places and at different times).

----------
nosy: +gdr at garethrees.org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Mon Oct 30 05:33:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 09:33:59 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509356039.15.0.213398074469.issue31897@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +4140
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 05:34:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 09:34:39 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509356079.76.0.213398074469.issue31897@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 05:37:33 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 30 Oct 2017 09:37:33 +0000
Subject: [issue31114] 'make install' fails when the configure 'prefix' is '/'
 and DESTDIR is used
In-Reply-To: <1501782040.16.0.9530512469.issue31114@psf.upfronthosting.co.za>
Message-ID: <1509356253.58.0.213398074469.issue31114@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
components: +Cross-Build -Build
nosy: +Alex.Willmer
stage:  -> needs patch
title: 'make install' fails when exec_prefix is '/' and DESTDIR not empty -> 'make install' fails when the configure 'prefix' is '/' and DESTDIR is used
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31114>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:05:08 2017
From: report at bugs.python.org (Erik Bray)
Date: Mon, 30 Oct 2017 10:05:08 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509357908.69.0.213398074469.issue31883@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Well, I agree there's an unfortunate trade-off here: One can skip the test, allowing the test suite to work on slightly older versions of Cygwin, from before this issue was fixed.  However, I then lose regression testing on newer versions.  My personal feeling in this case is that it's not a very important test and can be skipped in the future (although the bug that this test caught was fairly serious and one would want regression testing for it...)

As an alternative I could be more fine-grained and only skip the test on older versions of Cygwin that are affected.  I was hoping to avoid putting in too much Cygwin-specific test utilities, though adding a version check for Cygwin is not terribly hard (I do the same for my Cygwin port of psutil).

For reference, the current version of Cygwin that comes installed on AppVeyor (for which I'm trying to get a Cygwin build set up) is 2.8.0, which *is* (just barely) affected by this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:10:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 10:10:13 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509358213.08.0.213398074469.issue31897@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 4171 fixes the following errors:

1. OverflowError is raised by seek() for too large offsets of objects or the offset table.

2. Since read() past the file returns b'' and int.from_bytes() used for non-standard sizes accepts b'', bogus offsets and references can be read. This can cause an infinity recursion.

3. The zero size of offsets or references causes ValueError. This is implementation detail.

4. Unicode errors of decoding from invalid ASCII and UTF-8.

It doesn't verify the binary plist, a bogus plist can be successfully parsed to a bogus data. And it doesn't prevent infinity recursion when read cyclic references.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:14:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 10:14:51 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509358491.82.0.213398074469.issue31883@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a problem of AppVeyor. It should update Cygwin to a bugfix release. 2.8.0 contains other bugs.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:36:52 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 30 Oct 2017 10:36:52 +0000
Subject: [issue31114] 'make install' fails when the configure 'prefix' is '/'
 and DESTDIR is used
In-Reply-To: <1501782040.16.0.9530512469.issue31114@psf.upfronthosting.co.za>
Message-ID: <1509359812.06.0.213398074469.issue31114@psf.upfronthosting.co.za>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +4141
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31114>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:48:44 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 30 Oct 2017 10:48:44 +0000
Subject: [issue31114] 'make install' fails when the configure 'prefix' is '/'
 and DESTDIR is used
In-Reply-To: <1501782040.16.0.9530512469.issue31114@psf.upfronthosting.co.za>
Message-ID: <1509360524.61.0.213398074469.issue31114@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

To test PR 4172 on linux one needs a chroot. The following test is run on archlinux using systemd-nspawn (a chroot on steroids, see https://wiki.archlinux.org/index.php/Systemd-nspawn).

1) Setup systemd-nspawn by installing arch-install-scripts and by using pacstrap to install the archlinux 'base' package group in the /tmp/chroot container, this installs about 600M of archlinux packages in the chroot:
  $ mkdir /tmp/chroot
  $ pacman -S arch-install-scripts
  # pacstrap -i -c -d /tmp/chroot base --ignore linux

2) Build and install Python in the /tmp/python-build DESTDIR directory:
  $ mkdir /tmp/python-build
  $ ./configure --prefix=/ --without-ensurepip && make
  $ make DESTDIR=/tmp/python-build install

3) Copy the Python distribution to the chroot directory (note the trailing slash in the source directory):
  # rsync -av --keep-dirlinks /tmp/python-build/ /tmp/chroot

4) Boot into the chroot container and run python:
  # systemd-nspawn -b -D /tmp/chroot
  ...
  [  OK  ] Started Console Getty.
  [  OK  ] Reached target Login Prompts.
  [  OK  ] Started Login Service.
  [  OK  ] Reached target Multi-User System.
  [  OK  ] Reached target Graphical Interface.
  [  OK  ] Started Rotate log files.

  Arch Linux 4.13.4-1-ARCH (console)

  chroot login: root
  Last login: Mon Oct 30 10:54:11 on console
  [root at chroot ~]# python3.7
  Python 3.7.0a2+ (heads/bpo-31114:ffa5bff252, Oct 30 2017, 11:24:54)
  [GCC 7.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import abc, _bisect, sysconfig, sys
  >>> sys.prefix
  '/usr'
  >>> sysconfig.get_config_var('prefix')
  '/.'
  >>> sys.exit(0)
  [root at chroot ~]# poweroff
  ...
  [  OK  ] Reached target Shutdown.
  Container chroot has been shut down.

----------
nosy: +martin.panter, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31114>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:58:08 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 30 Oct 2017 10:58:08 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509361088.25.0.213398074469.issue31895@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I agree with Steven: It's best to use a PyPI package for calendar support such as https://pypi.python.org/pypi/convertdate/.

We only have the standard Gregorian calendar support in datetime and calendar modules.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Mon Oct 30 06:59:56 2017
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 30 Oct 2017 10:59:56 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1509361196.75.0.213398074469.issue25612@psf.upfronthosting.co.za>


Mark Shannon <mark at hotpy.org> added the comment:

Looking at the docs:

https://docs.python.org/3.6/library/sys.html#sys.exc_info states:
     If the current stack frame is not handling an exception, the information is taken from the calling stack frame, or its caller, and so on until a stack frame is found that is handling an exception.

And https://docs.python.org/3/reference/simple_stmts.html#the-raise-statement

If no expressions are present, raise re-raises the last exception that was active in the current scope. If no exception is active in the current scope, a RuntimeError exception is raised indicating that this is an error.

Note that `sys.exc_info()` explicitly mentions scanning the stack, but `raise` just says "active in the current scope". Testing on 3.5 shows that "active in the current scope" does scan the stack (for simple calls at least).

Which means that the newly implemented behaviour is correct.



> Note that removing exc_type, exc_value and exc_traceback from PyThreadState breaks Cython.

Is there a matching Cython issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Mon Oct 30 07:06:41 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 30 Oct 2017 11:06:41 +0000
Subject: [issue31114] 'make install' fails when the configure 'prefix' is '/'
 and DESTDIR is used
In-Reply-To: <1501782040.16.0.9530512469.issue31114@psf.upfronthosting.co.za>
Message-ID: <1509361601.34.0.213398074469.issue31114@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Clarification about the test results:
On archlinux /bin is a symlink to /usr/bin, so on archlinux the value of sys.prefix is '/usr' instead of the expected '/'. This is because in Modules/getpath.c, 'argv0_path' is the directory of the link target when the executable location is a symbolic link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31114>
_______________________________________

From report at bugs.python.org  Mon Oct 30 07:11:05 2017
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 30 Oct 2017 11:11:05 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509361865.31.0.213398074469.issue31895@psf.upfronthosting.co.za>


Gareth Rees <gdr at garethrees.org> added the comment:

convertdate does not document which version of the Islamic calendar it uses, but looking at the source code, it seems that it uses a rule-based calendar which has a 30-year cycle with 11 leap years. This won't help Haneef, who wants the Umm al-Qura calendar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Mon Oct 30 07:37:04 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 11:37:04 +0000
Subject: [issue25612] nested try..excepts don't work correctly for generators
In-Reply-To: <1447361959.0.0.839122121456.issue25612@psf.upfronthosting.co.za>
Message-ID: <1509363424.07.0.213398074469.issue25612@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for the clarification Mark. I agree that the current behavior is well justified.

Cython was fixed in https://github.com/cython/cython/commit/2d3392463b77eb550bd54a69bd28cc161947acb5.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25612>
_______________________________________

From report at bugs.python.org  Mon Oct 30 07:38:25 2017
From: report at bugs.python.org (Erik Bray)
Date: Mon, 30 Oct 2017 11:38:25 +0000
Subject: [issue31883] Cygwin: heap corruption bug in wcsxfrm
In-Reply-To: <1509111731.98.0.213398074469.issue31883@psf.upfronthosting.co.za>
Message-ID: <1509363505.89.0.213398074469.issue31883@psf.upfronthosting.co.za>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Well, we'll see how long it takes me to get them to respond on that.  If it's not too much trouble then I'll be happy to drop this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31883>
_______________________________________

From report at bugs.python.org  Mon Oct 30 08:10:49 2017
From: report at bugs.python.org (Haneef)
Date: Mon, 30 Oct 2017 12:10:49 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509365449.38.0.213398074469.issue31895@psf.upfronthosting.co.za>


Haneef <haneef95 at gmail.com> added the comment:

Thanks @steven.daprano, yeah, it would be good to have support for other calendars as well.

In my case, I use the Hijri Umm al-Qura, Gregorian and obviously UnixTime calendars.

You're right, maybe it would be wiser to implement it in the PyPi first and then move it to a standard Python library.

@Lemburg, I checked out the PyPi convertdate library, as Gareth mentioned, it doesn't specify which Islamic calendar it is implementing and had a look at the code, it doesn't look like Umm al-Qura. It seems to be a very roughly calculated Tabular Lunar Calendar (with Hijrah as the reference point), no where near accurate to the actual lunar cycles.


@Gareth
To explain Islamic Hijri Calendar in short, it is basically a sighted Lunar calendar, which has to be sighted at the end of every month to determine the beginning of the next month. Therefore, it is not possible to determine the dates in future (beyond 29th of the month). Every month could be 29 or 30 days. There are 12 months and 354 days in a year.
However, to solve this issue, Muslim astronomers and Scholars over the course of History (1400years) have used two different types of Hijri calendars; one sighted and another calculated. The sighted version of the calendar is accurate but cannot go beyond 29th of the current month.
The astronomically calculated version could go up-to a fixed period which the astronomers have calculated. The calculated/civil calendar is used for Visas, deeds, bank statements, appointments and other civil matters in their respective countries.

One of the predominantly used and astronomically calculated Hijri calendars is the Umm al-Qura Hijri calendar. It was calculated by scholars & astronomers at the Umm al-Qura (Makkah) University.

Sorry about the long post, hope this helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Mon Oct 30 08:29:40 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 30 Oct 2017 12:29:40 +0000
Subject: [issue31895] Native hijri calendar support
In-Reply-To: <1509325061.68.0.213398074469.issue31895@psf.upfronthosting.co.za>
Message-ID: <1509366580.65.0.213398074469.issue31895@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

There are other PyPI packages available for this specific calendar as well, e.g. https://pypi.python.org/pypi/umalqurra/

Perhaps you could send Neil a PR to make the calculation more accurate ?!

In any case, the stdlib is not meant to cover everything, only a basic subset of functionality, so adding support for more than just one calendar is out of scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31895>
_______________________________________

From report at bugs.python.org  Mon Oct 30 09:41:05 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 30 Oct 2017 13:41:05 +0000
Subject: [issue31900] UnicodeDecodeError in localeconv() makes test_float fail
 with glibc 2.26.90
Message-ID: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1484497

It seems that on the development branch of Fedora, when we updated glibc from 2.26 to 2.26.90, test_float_with_comma started failing.

Details from the original bug report:

Under certain circumstances, when LC_NUMERIC is fr_FR.ISO8859-1 but LC_ALL is C.UTF-8, locale.localeconv() fails with
    UnicodeDecodeError: 'locale' codec can't decode byte 0xa0 in position 0: Invalid or incomplete multibyte or wide character

Apparently, the thousands separator (or something else) in the lconv is "\xa0" (unbreakable space in fr_FR.ISO8859-1), and it's being decoded with UTF-8.

This is tripped by Python's test suite, namely test_float.GeneralFloatCases.test_float_with_comma

----------
components: Tests
messages: 305227
nosy: cstratak
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 09:43:08 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 30 Oct 2017 13:43:08 +0000
Subject: [issue31245] Asyncio UNIX socket and SOCK_DGRAM
In-Reply-To: <1503324419.78.0.551838104662.issue31245@psf.upfronthosting.co.za>
Message-ID: <1509370988.93.0.213398074469.issue31245@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset fe4ea9cf1ee04f5a60e4ed928d8624b95b031e18 by Yury Selivanov (Quentin Dawans) in branch 'master':
bpo-31245: Asyncio unix socket datagram (#3164)
https://github.com/python/cpython/commit/fe4ea9cf1ee04f5a60e4ed928d8624b95b031e18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31245>
_______________________________________

From report at bugs.python.org  Mon Oct 30 09:43:36 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 30 Oct 2017 13:43:36 +0000
Subject: [issue31245] Asyncio UNIX socket and SOCK_DGRAM
In-Reply-To: <1503324419.78.0.551838104662.issue31245@psf.upfronthosting.co.za>
Message-ID: <1509371016.12.0.213398074469.issue31245@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31245>
_______________________________________

From report at bugs.python.org  Mon Oct 30 10:53:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 14:53:19 +0000
Subject: [issue31900] UnicodeDecodeError in localeconv() makes test_float fail
 with glibc 2.26.90
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509375199.57.0.213398074469.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I can reproduce the bug with Python 3.6 on Fedora 26 and these locales:

* LC_ALL = LC_CTYPE = fr_FR (encoding = ISO8859-1)
* LC_NUMERIC= es_MX.utf8 (encoding = UTF-8)


Good: LC_NUMERIC = LC_CTYPE = LC_ALL = "es_MX.utf8"

haypo at selma$ env -i python3 -c 'import locale; locale.setlocale(locale.LC_ALL, "es_MX.utf8"); print(ascii(locale.localeconv()["thousands_sep"]))'

=> '\u2009'


Bug: LC_NUMERIC = "es_MX.utf8" but LC_CTYPE = LC_ALL = "fr_FR"

haypo at selma$ env -i python3 -c 'import locale; locale.setlocale(locale.LC_ALL, "fr_FR"); locale.setlocale(locale.LC_NUMERIC, "es_MX.utf8"); print(ascii(locale.localeconv()["thousands_sep"]))'

=> '\xe2\x80\x89'

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 10:56:20 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 14:56:20 +0000
Subject: [issue31900] localeconv() should decide numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509375380.48.0.213398074469.issue31900@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
title: UnicodeDecodeError in localeconv() makes test_float fail with glibc 2.26.90 -> localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 10:57:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 14:57:38 +0000
Subject: [issue31900] localeconv() should decide numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509375458.47.0.213398074469.issue31900@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
pull_requests: +4142
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 10:58:49 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 14:58:49 +0000
Subject: [issue31900] localeconv() should decide numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509375529.52.0.213398074469.issue31900@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 11:25:58 2017
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 30 Oct 2017 15:25:58 +0000
Subject: [issue31900] localeconv() should decide numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509377158.18.0.213398074469.issue31900@psf.upfronthosting.co.za>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Tested the PR on a system with glibc 2.26.90 where the test was failing, and it successfully passed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 11:32:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 15:32:38 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509377558.52.0.213398074469.issue31900@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
title: localeconv() should decide numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding -> localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 11:34:11 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 15:34:11 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509377651.36.0.213398074469.issue31900@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue28604. See also issue25812.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 11:44:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 15:44:10 +0000
Subject: [issue31273] [2.7] unittest: Unicode support in TestCase.skip
In-Reply-To: <1503607033.04.0.29955978966.issue31273@psf.upfronthosting.co.za>
Message-ID: <1509378250.06.0.213398074469.issue31273@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Could be fixed with by changing to unicode(e)

Replacing str(e) with unicode(e) can introduce Unicode errors regressions. I'm not confident in doing such change late in the old 2.7 branch.

I suggest you to only use native strings (byte strings, "str" type) in Python 2, and slowly upgrade your application to Python 3.

I propose to close this issue as WONT FIX.

----------
title: Unicode support in TestCase.skip -> [2.7] unittest: Unicode support in TestCase.skip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31273>
_______________________________________

From report at bugs.python.org  Mon Oct 30 11:44:43 2017
From: report at bugs.python.org (Marcel Plch)
Date: Mon, 30 Oct 2017 15:44:43 +0000
Subject: [issue31901] atexit callbacks only called for current subinterpreter
Message-ID: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za>


New submission from Marcel Plch <gmarcel.plch at gmail.com>:

`Py_FinalizeEx()` only executes callbacks from the subinterpreter from which Py_FinalizeEx is called.

What is the expected behavior here?
Should the callbacks be specific to individual subinterpreters?

----------
components: Extension Modules
messages: 305233
nosy: Dormouse759, encukou, ncoghlan
priority: normal
severity: normal
status: open
title: atexit callbacks only called for current subinterpreter
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31901>
_______________________________________

From report at bugs.python.org  Mon Oct 30 11:55:20 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Oct 2017 15:55:20 +0000
Subject: [issue31273] [2.7] unittest: Unicode support in TestCase.skip
In-Reply-To: <1503607033.04.0.29955978966.issue31273@psf.upfronthosting.co.za>
Message-ID: <1509378920.1.0.213398074469.issue31273@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Victor. Unlikely this affects many people since skipping messages usually are ASCII strings.

As a workaround you can implement your own skip() method that encodes unicode to 8-bit string.

    def skip(self, reason):
        if isinstance(reason, unicode):
            reason = unicode.encode(reason, 'utf-8')
        TestCase.skip(self, reason)

----------
nosy: +serhiy.storchaka
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31273>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:02:37 2017
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Oct 2017 16:02:37 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509379357.63.0.213398074469.issue31900@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Same as #7442, I think.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:13:01 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 16:13:01 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509379981.77.0.213398074469.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh wow, this bug is older than what I expected :-) I added support for non-ASCII thousands separator in 2012:

https://bugs.python.org/issue13706#msg151733

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:14:00 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 16:14:00 +0000
Subject: [issue31900] localeconv() should decode numeric fields from
 LC_NUMERIC encoding, not from LC_CTYPE encoding
In-Reply-To: <1509370865.74.0.213398074469.issue31900@psf.upfronthosting.co.za>
Message-ID: <1509380040.36.0.213398074469.issue31900@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

inconsistent_locale_encodings.py of closed issue #7442 is interesting: I copy it here.

----------
Added file: https://bugs.python.org/file47246/inconsistent_locale_encodings.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31900>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:14:48 2017
From: report at bugs.python.org (Guo Ci Teo)
Date: Mon, 30 Oct 2017 16:14:48 +0000
Subject: [issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef,
 AsyncWith
Message-ID: <1509380088.03.0.213398074469.issue31902@psf.upfronthosting.co.za>


Change by Guo Ci Teo <zguoci at gmail.com>:


----------
components: Library (Lib)
nosy: guoci
priority: normal
severity: normal
status: open
title: Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, AsyncWith
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31902>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:33:50 2017
From: report at bugs.python.org (Guo Ci Teo)
Date: Mon, 30 Oct 2017 16:33:50 +0000
Subject: [issue31902] Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef,
 AsyncWith
Message-ID: <1509381230.17.0.213398074469.issue31902@psf.upfronthosting.co.za>


Change by Guo Ci Teo <zguoci at gmail.com>:


----------
keywords: +patch
pull_requests: +4143
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31902>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:36:06 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 16:36:06 +0000
Subject: [issue30333] test_multiprocessing_forkserver: poll() failed on AMD64
 FreeBSD CURRENT Non-Debug 3.5
In-Reply-To: <1494429873.7.0.669335220252.issue30333@psf.upfronthosting.co.za>
Message-ID: <1509381366.03.0.213398074469.issue30333@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I didn't see this bug recently. I fixed many bugs in the meanwhile, so maybe I fixed the bug?

See for example https://haypo.github.io/contrib-cpython-2017q3-part2.html

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30333>
_______________________________________

From report at bugs.python.org  Mon Oct 30 12:38:34 2017
From: report at bugs.python.org (Guo Ci Teo)
Date: Mon, 30 Oct 2017 16:38:34 +0000
Subject: [issue29205] col_offset for AsyncFunctionDef AST nodes is wrong
In-Reply-To: <1483874960.49.0.58571949289.issue29205@psf.upfronthosting.co.za>
Message-ID: <1509381514.88.0.213398074469.issue29205@psf.upfronthosting.co.za>


Change by Guo Ci Teo <zguoci at gmail.com>:


----------
pull_requests: +4144
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29205>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:08:07 2017
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 30 Oct 2017 17:08:07 +0000
Subject: [issue31222] datetime.py implementation of .replace inconsistent with
 C implementation
In-Reply-To: <1502902905.88.0.809330827331.issue31222@psf.upfronthosting.co.za>
Message-ID: <1509383287.6.0.213398074469.issue31222@psf.upfronthosting.co.za>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
keywords: +patch
pull_requests: +4145
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31222>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:11:14 2017
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 30 Oct 2017 17:11:14 +0000
Subject: [issue31222] datetime.py implementation of .replace inconsistent with
 C implementation
In-Reply-To: <1502902905.88.0.809330827331.issue31222@psf.upfronthosting.co.za>
Message-ID: <1509383474.73.0.213398074469.issue31222@psf.upfronthosting.co.za>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Some time ago this was fixed in pypy3:

https://bitbucket.org/pypy/pypy/issues/2635/datetimereplace-always-returns

I made a PR fixing this for `datetime`, `date` and `time`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31222>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:24:15 2017
From: report at bugs.python.org (Jan Gosmann)
Date: Mon, 30 Oct 2017 17:24:15 +0000
Subject: [issue29515] socket module missing IPPROTO_IPV6,
 IPPROTO_IPV4 on Windows
In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za>
Message-ID: <1509384255.74.0.213398074469.issue29515@psf.upfronthosting.co.za>


Change by Jan Gosmann <jan+pythontracker at hyper-world.de>:


----------
nosy: +jgosmann

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29515>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:37:46 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 17:37:46 +0000
Subject: [issue31629] test_multiprocessing_fork failure on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509385066.48.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

test_many_processes() was added by bpo-30589. Antoine Pitrou commented:

"In the end, I'm glad I added a stress test (test_many_processes) as part of this issue.".

I confirm that test_multiprocessing_fork fails with "./python -m test -vuall" on FreeBSD CURRENT (I tested on Koobs's buildbot worker). I'm currently trying to bisect the issue. It's not easy since test_curses does randomly crash and running +200 tests sequentially is slow.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:38:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 17:38:10 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509385090.69.0.213398074469.issue31629@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
title: test_multiprocessing_fork failure on FreeBSD -> test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:40:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 17:40:40 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509385240.38.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Latest change in test_many_processes(): commit e6cfdefa0c2f5bda177e49b228c2c7528f7c239c of bpo-31510 which was specific to macOS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 13:41:34 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 17:41:34 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509385294.76.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

See also commit c08177a1ccad2ed0d50898c2731b518c631aed14 of bpo-30703.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 14:39:31 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 30 Oct 2017 18:39:31 +0000
Subject: [issue31304] Update doc for starmap_async error_back kwarg
In-Reply-To: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>
Message-ID: <1509388771.23.0.213398074469.issue31304@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 11225753a89c2907bb717e6c050fe907e5e11829 by Mariatta (Pablo Galindo) in branch 'master':
bpo-31304: Update starmap_async documentation. (GH-4168)
https://github.com/python/cpython/commit/11225753a89c2907bb717e6c050fe907e5e11829


----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31304>
_______________________________________

From report at bugs.python.org  Mon Oct 30 14:39:40 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Oct 2017 18:39:40 +0000
Subject: [issue31304] Update doc for starmap_async error_back kwarg
In-Reply-To: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>
Message-ID: <1509388780.93.0.213398074469.issue31304@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31304>
_______________________________________

From report at bugs.python.org  Mon Oct 30 14:47:41 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 30 Oct 2017 18:47:41 +0000
Subject: [issue31304] Update doc for starmap_async error_back kwarg
In-Reply-To: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>
Message-ID: <1509389261.49.0.213398074469.issue31304@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 2702380870b63ebe0161dfa29a2d0a3de02401b4 by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-31304: Update starmap_async documentation. (GH-4168) (GH-4177)
https://github.com/python/cpython/commit/2702380870b63ebe0161dfa29a2d0a3de02401b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31304>
_______________________________________

From report at bugs.python.org  Mon Oct 30 14:48:42 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 30 Oct 2017 18:48:42 +0000
Subject: [issue31304] Update doc for starmap_async error_back kwarg
In-Reply-To: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>
Message-ID: <1509389322.8.0.213398074469.issue31304@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

This has been fixed. Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31304>
_______________________________________

From report at bugs.python.org  Mon Oct 30 15:38:53 2017
From: report at bugs.python.org (Maxime Belanger)
Date: Mon, 30 Oct 2017 19:38:53 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
Message-ID: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>


New submission from Maxime Belanger <max at dropbox.com>:

Through the use of various Python packages (such as `pyobjc`), it is possible for a deadlock to occur due to how `_scproxy.c` calls `SCDynamicStoreCopyProxies`.

In more recent versions of macOS (10.7+), this function can block on acquiring a lock deep inside `NSUserPreferences`. As `pyobjc` allows Python-wrapped `NSString`s to be stored in `CFPreferences`, it is thus possible for one thread to hold the `CFPreferences` lock and block on the GIL while another thread holds the GIL and blocks on the `CFPreferences` lock.

We've observed this on a significant number of macOS devices before fixing ourselves by wrapping the calls to `SCDynamicStoreCopyProxies` with `Py_BEGIN/END_ALLOW_THREADS`.

----------
components: macOS
messages: 305247
nosy: Maxime Belanger, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: `_scproxy` calls SystemConfiguration functions in a way that can cause deadlocks
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Mon Oct 30 15:56:20 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 30 Oct 2017 19:56:20 +0000
Subject: [issue31114] 'make install' fails when the configure 'prefix' is '/'
 and DESTDIR is used
In-Reply-To: <1501782040.16.0.9530512469.issue31114@psf.upfronthosting.co.za>
Message-ID: <1509393380.02.0.213398074469.issue31114@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Actually, sys.prefix is '/usr' because '/usr/bin' is in PATH while '/bin' is not in PATH. After adding '/bin' to the start of PATH, then sys.prefix becomes '/.' when Python is run as 'python3'. The confusion comes from the '/bin' symlink (archlinux is not a perfect choice for those tests). Whatever the value of PATH, '/bin/python3' has also '/.' as its sys.prefix.

So Modules/getpath.c fails to get '/' as the prefix in step 3 of the algorithm described at the top of the source code and uses '/.' (i.e. PREFIX) instead. This is caused by its reduce() function not handling the corner case where Python is installed on '/'. I will update the PR shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31114>
_______________________________________

From report at bugs.python.org  Mon Oct 30 15:56:33 2017
From: report at bugs.python.org (Brian Kuhl)
Date: Mon, 30 Oct 2017 19:56:33 +0000
Subject: [issue31904] Python should support VxWorks RTOS
Message-ID: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>


New submission from Brian Kuhl <kuhlenough at gmail.com>:

With the trend to use REST APIs between the cloud and the IoT there is increasing interest in Python on embedded devices.  Cloud developer?s typical release a reference REST implementation of JSON and/or Python on Linux and leave it to the device developer to adapt it to their platform.   While many devices use eLinux, others with IP and/or hard real-time constraints need a commercial RTOS platform. 

Currently the automake configure explicitly prevents configuration of VxWorks as a build target.

I'll provide a pull request referencing this issue with the required changes.

----------
components: Cross-Build
messages: 305249
nosy: Alex.Willmer, Brian Kuhl
priority: normal
severity: normal
status: open
title: Python should support VxWorks RTOS
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Mon Oct 30 15:59:15 2017
From: report at bugs.python.org (=?utf-8?q?Max_B=C3=A9langer?=)
Date: Mon, 30 Oct 2017 19:59:15 +0000
Subject: [issue31903] `_scproxy` calls SystemConfiguration functions in a way
 that can cause deadlocks
In-Reply-To: <1509392333.58.0.213398074469.issue31903@psf.upfronthosting.co.za>
Message-ID: <1509393555.7.0.213398074469.issue31903@psf.upfronthosting.co.za>


Change by Max B?langer <aeromax at gmail.com>:


----------
keywords: +patch
pull_requests: +4148
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31903>
_______________________________________

From report at bugs.python.org  Mon Oct 30 16:46:47 2017
From: report at bugs.python.org (Brian Kuhl)
Date: Mon, 30 Oct 2017 20:46:47 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1509396407.81.0.213398074469.issue31904@psf.upfronthosting.co.za>


Change by Brian Kuhl <kuhlenough at gmail.com>:


----------
keywords: +patch
pull_requests: +4149
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Mon Oct 30 16:56:08 2017
From: report at bugs.python.org (Gerard Weatherby)
Date: Mon, 30 Oct 2017 20:56:08 +0000
Subject: [issue31905] IPv4Networkcontains raises exception on None
Message-ID: <1509396968.75.0.213398074469.issue31905@psf.upfronthosting.co.za>


New submission from Gerard Weatherby <gerard.weatherby at gmail.com>:

Given a IPvNetwork network
if x in network:
   ...

raises an AttributeError instead of returning False.

----------
components: Library (Lib)
files: ne.py
messages: 305250
nosy: Gerard Weatherby
priority: normal
severity: normal
status: open
title: IPv4Networkcontains raises exception on None
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47247/ne.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31905>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:08:24 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Oct 2017 21:08:24 +0000
Subject: [issue31905] IPv4Networkcontains raises exception on None
In-Reply-To: <1509396968.75.0.213398074469.issue31905@psf.upfronthosting.co.za>
Message-ID: <1509397704.63.0.213398074469.issue31905@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4150
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31905>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:19:28 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Oct 2017 21:19:28 +0000
Subject: [issue31905] IPv4Networkcontains raises exception on None
In-Reply-To: <1509396968.75.0.213398074469.issue31905@psf.upfronthosting.co.za>
Message-ID: <1509398368.24.0.213398074469.issue31905@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is not obvious that this is a bug.  Why should None be a valid value for 'in network'?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31905>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:30:46 2017
From: report at bugs.python.org (Sam Lobel)
Date: Mon, 30 Oct 2017 21:30:46 +0000
Subject: [issue31906] String literals next to each other does not cause error
Message-ID: <1509399045.99.0.213398074469.issue31906@psf.upfronthosting.co.za>


New submission from Sam Lobel <slobel at lexile.com>:

This seems too obvious to have been missed, but also too strange behaviour to be on purpose.

The following works for some reason (note there's no + between the words)
>>> variable = "first" "second"
>>> print(variable)
"firstsecond"

In a file, if you're missing a comma between two string literals, it combines them into one string (instead of throwing a syntax error). E.G:

>>> a = ["first",
... "second"
... "third"]
>>> print(a)
["first" "secondthird"]

BUT, the same thing with variables (thankfully) does not work.
>>> a = "first"
>>> b = "second"
>>> c = a b
Throws a syntax error.

The same sort of thing also breaks for integers.
>>> a = 4 7
throws a syntax error.

This just seems wrong to me. Is it? Has this been discussed a million times before?

----------
messages: 305252
nosy: Sam Lobel2
priority: normal
severity: normal
status: open
title: String literals next to each other does not cause error
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31906>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:33:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 21:33:57 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509399237.45.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Running these two tests is enough to reproduce the issue:

test.test_curses.TestCurses.test_new_curses_panel
test.test_multiprocessing_fork.WithProcessesTestProcess.test_many_processes

Command:

CURRENT-amd64% ./python -m test -vuall test_curses  test_multiprocessing_fork  -m test.test_curses.TestCurses.test_new_curses_panel -m test.test_multiprocessing_fork.WithProcessesTestProcess.test_many_processes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:35:56 2017
From: report at bugs.python.org (Sam Lobel)
Date: Mon, 30 Oct 2017 21:35:56 +0000
Subject: [issue31906] String literals next to each other does not cause error
In-Reply-To: <1509399045.99.0.213398074469.issue31906@psf.upfronthosting.co.za>
Message-ID: <1509399356.81.0.213398074469.issue31906@psf.upfronthosting.co.za>


Change by Sam Lobel <slobel at lexile.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31906>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:44:49 2017
From: report at bugs.python.org (Ned Williamson)
Date: Mon, 30 Oct 2017 21:44:49 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509399889.21.0.213398074469.issue31897@psf.upfronthosting.co.za>


Ned Williamson <nedwilliamson at gmail.com> added the comment:

Thank you for the quick PR! I will report as behavior next time. I'm also following the library reference and reporting only unexpected exceptions.

I trust you to reject any bugs that are expected functionality.

I may follow up with additional testcases once the first PR is accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:49:03 2017
From: report at bugs.python.org (Dmitry Kazakov)
Date: Mon, 30 Oct 2017 21:49:03 +0000
Subject: [issue31906] String literals next to each other does not cause error
In-Reply-To: <1509399045.99.0.213398074469.issue31906@psf.upfronthosting.co.za>
Message-ID: <1509400143.13.0.213398074469.issue31906@psf.upfronthosting.co.za>


Dmitry Kazakov <waultah+py at gmail.com> added the comment:

This is a documented feature: https://docs.python.org/3/reference/lexical_analysis.html#string-literal-concatenation

And yes, it was discussed before: https://mail.python.org/pipermail/python-ideas/2013-May/020527.html

----------
nosy: +vaultah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31906>
_______________________________________

From report at bugs.python.org  Mon Oct 30 17:51:17 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 30 Oct 2017 21:51:17 +0000
Subject: [issue31906] String literals next to each other does not cause error
In-Reply-To: <1509399045.99.0.213398074469.issue31906@psf.upfronthosting.co.za>
Message-ID: <1509400277.01.0.213398074469.issue31906@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

What Dmitry said :) I'm closing this as "not a bug".

----------
nosy: +Mariatta
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31906>
_______________________________________

From report at bugs.python.org  Mon Oct 30 18:38:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Oct 2017 22:38:54 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509403134.7.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The bug can be reproduced with attached bug.py.

With "curses.initscr(); curses.endwin()", the exit code becomes 1.

Without, the child processes exits with code -15 (-SIGTERM).

----------
Added file: https://bugs.python.org/file47248/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 19:05:47 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Oct 2017 23:05:47 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1509404747.93.0.213398074469.issue31739@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4152
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Mon Oct 30 19:26:09 2017
From: report at bugs.python.org (Adam Mitchell)
Date: Mon, 30 Oct 2017 23:26:09 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1509405969.21.0.213398074469.issue31739@psf.upfronthosting.co.za>


Adam Mitchell <adam0500 at me.com> added the comment:

I submitted a pull request, #4181, to fix this issue. I am now waiting for my contributor agreement to be approved.

----------
nosy: +AdamMitchell

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Mon Oct 30 19:28:16 2017
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 30 Oct 2017 23:28:16 +0000
Subject: [issue31739] socket.close recommended but not demonstrated in
 same-page example code
In-Reply-To: <1507577278.77.0.213398074469.issue31739@psf.upfronthosting.co.za>
Message-ID: <1509406096.0.0.213398074469.issue31739@psf.upfronthosting.co.za>


Change by Todd Rovito <rovitotv at rovitotv.org>:


----------
nosy: +Todd.Rovito

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31739>
_______________________________________

From report at bugs.python.org  Mon Oct 30 19:50:14 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Oct 2017 23:50:14 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509407414.42.0.213398074469.issue31629@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have tracked the issue down to the call inside the call to initscr in _cursesmodule.c. The issue *seems* related to the fact that all processes are sharing the same initialization of the curses internal structures, that (probably) is also related to an error that happens when calling initscr multiple times. Notice that:

def sleep_some():
    curses.initscr()
    curses.endwin()
    time.sleep(100)

(without calling initscr in the parent)

yields the correct results:

-15 -15
-15 -15
-15 -15

while doing the same but interleaving one all to initscr after the first fork:

for p in procs:
    p.start()
    curses.initscr()

yields correct results for the first child but incorrect for the rest:

-15 -15
1 -15
1 -15

It seems that forking (because spawn or forkserver always works) after doing the call to initscr does something to the child that makes it unable to handle/receive SIGTERM. The exit statuses of this last round are:

[pid 27105] +++ killed by SIGTERM +++
[pid 27104] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=27105, si_uid=1000, si_status=SIGTERM, si_utime=0, si_stime=0} ---
[pid 27106] +++ exited with 1 +++
[pid 27104] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27106, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---
[pid 27107] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27107, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:11:25 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Oct 2017 00:11:25 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509408685.73.0.213398074469.issue31629@psf.upfronthosting.co.za>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Also, it seems that calling initscr registers signal handlers for SIGTERM:

Without calling initscr:

...


rt_sigaction(SIGINT, {sa_handler=0x55d9351a9155, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f7d22b36da0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f7d22b36da0}, {sa_handler=0x55d9351a9155, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f7d22b36da0}, 8) = 0
sigaltstack(NULL, {ss_sp=0x55d93743a1c0, ss_flags=0, ss_size=8192}) = 0
sigaltstack({ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}, NULL) = 0

...

Calling initscr:

...

 rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0                                                                                                                                                                                                        rt_sigaction(SIGTERM, {sa_handler=0x7f28d6affed0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f28d7c8eda0}, NULL, 8) = 0
 rt_sigaction(SIGWINCH, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0                                                                                                                                                                                                           rt_sigaction(SIGWINCH, {sa_handler=0x7f1046394ec0, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f1047523da0}, NULL, 8) = 0
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:19:32 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 31 Oct 2017 00:19:32 +0000
Subject: [issue31905] IPv4Networkcontains raises exception on None
In-Reply-To: <1509396968.75.0.213398074469.issue31905@psf.upfronthosting.co.za>
Message-ID: <1509409172.91.0.213398074469.issue31905@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with David. And since the PR says "not other", then it makes even less sense, since it's checking for any False-y object.

I recommend closing this as "not a bug".

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31905>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:24:00 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 00:24:00 +0000
Subject: [issue31629] test_many_processes() of test_multiprocessing_fork fails
 randomly on FreeBSD
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509409440.65.0.213398074469.issue31629@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
pull_requests: +4154
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:35:20 2017
From: report at bugs.python.org (mickey695)
Date: Tue, 31 Oct 2017 00:35:20 +0000
Subject: [issue31907] Clarify error message when attempting to call function
 via str.format()
Message-ID: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>


New submission from mickey695 <mickey695 at gmail.com>:

PEP 3101 states that format strings may only use the "."(getattr) or the "[]" (getitem) operators to address either attributes or items of parameters.
Should a programmer attempt to, for example, call a function of a parameter as follows: 

>>> d = datetime.datetime(2017, 10, 31)
>>> "{0.ctime()}".format(d)

they will receive an error message such as:

AttributeError: 'datetime.datetime' object has no attribute 'ctime()'

Proposal:
Raise an error stating that cannot embed arbitrary expressions in str.format() format strings

----------
components: Interpreter Core
messages: 305263
nosy: mickey695
priority: normal
severity: normal
status: open
title: Clarify error message when attempting to call function via str.format()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:42:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 00:42:10 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509410530.23.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Pablo Galindo Salgado:
> Also, it seems that calling initscr registers signal handlers for SIGTERM: (...)

The problem is that endwin() doesn't restore the old handler.

Attached PR 4183 fixes the bug, it saves/restores signal handlers:

./python -m test -vuall test_curses  test_multiprocessing_fork -m test.test_curses.TestCurses.test_new_curses_panel -m test.test_multiprocessing_fork.WithProcessesTestProcess.test_many_processes

----------
title: test_many_processes() of test_multiprocessing_fork fails randomly on FreeBSD -> Running test_curses on FreeBSD changes signal handlers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:46:38 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 00:46:38 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1509410798.86.0.213398074469.issue31852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 690c36f2f1085145d364a89bfed5944dd2470308 by Victor Stinner (Pablo Galindo) in branch '3.6':
[3.6] bpo-31852: Fix segfault caused by using the async soft keyword (GH-4122)
https://github.com/python/cpython/commit/690c36f2f1085145d364a89bfed5944dd2470308


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:49:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 00:49:59 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1509410999.21.0.213398074469.issue31852@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Mon Oct 30 20:50:32 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 00:50:32 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1509411032.01.0.213398074469.issue31852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Thank you Alexandre Hamelin for the bug report and Pablo Galindo for the fix ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Mon Oct 30 22:44:01 2017
From: report at bugs.python.org (Alexandre Hamelin)
Date: Tue, 31 Oct 2017 02:44:01 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1509417841.01.0.213398074469.issue31852@psf.upfronthosting.co.za>


Alexandre Hamelin <quad.on at gmail.com> added the comment:

Awesome work, thanks to you!

Would it also be the case for 'await' ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Mon Oct 30 22:55:06 2017
From: report at bugs.python.org (Michael Selik)
Date: Tue, 31 Oct 2017 02:55:06 +0000
Subject: [issue31908] trace module cli does not write cover files
Message-ID: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>


New submission from Michael Selik <michael.selik at gmail.com>:

The trace module command-line utility doesn't write cover files. I've noticed this issue for some years now. It works fine in Python 2. When using Python 3, no ".cover" files are written, regardless of how "--coverdir" is specified.

    mike on macbook in ~/
    $ echo 'print("hello")' > foo.py

    mike on macbook in ~/
    $ python -m trace --count foo.py
    hello

    mike on macbook in ~/
    $ ls *.cover
    ls: *.cover: No such file or directory


My apologies if this is a duplicate bug. I searched the tracker and Google for a while, but couldn't find a relevant issue.

----------
messages: 305268
nosy: Michael Selik
priority: normal
severity: normal
status: open
title: trace module cli does not write cover files
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Mon Oct 30 23:13:38 2017
From: report at bugs.python.org (Brian Kuhl)
Date: Tue, 31 Oct 2017 03:13:38 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1509419618.54.0.213398074469.issue31904@psf.upfronthosting.co.za>


Change by Brian Kuhl <kuhlenough at gmail.com>:


----------
pull_requests: +4155

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Oct 31 00:19:24 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Oct 2017 04:19:24 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1509423564.94.0.213398074469.issue31908@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It worked in Python 3.4, but not afterwards.

----------
components: +Library (Lib)
nosy: +rhettinger
versions: +Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Tue Oct 31 02:29:04 2017
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 31 Oct 2017 06:29:04 +0000
Subject: [issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
Message-ID: <1509431344.9.0.213398074469.issue31909@psf.upfronthosting.co.za>


New submission from Ilya Kulakov <kulakov.ilya at gmail.com>:

Python 3.5 and 3.6 in their corresponding configure.ac try to detect presence of sys_getrandom. The result is written into the `HAVE_GETRANDOM_SYSCALL` definition.

libexpact checks for `HAVE_SYSCALL_GETRANDOM` and since it's not defined, does not use it. This fails compilation with up to date libexpact due to a new condition [1].

[1] https://github.com/python/cpython/blob/master/Modules/expat/xmlparse.c#L87-L91

----------
components: Build
messages: 305270
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: Missing definition of HAVE_SYSCALL_GETRANDOM
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31909>
_______________________________________

From report at bugs.python.org  Tue Oct 31 02:41:17 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 06:41:17 +0000
Subject: [issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
In-Reply-To: <1509431344.9.0.213398074469.issue31909@psf.upfronthosting.co.za>
Message-ID: <1509432077.79.0.213398074469.issue31909@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +4156
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31909>
_______________________________________

From report at bugs.python.org  Tue Oct 31 02:47:14 2017
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 31 Oct 2017 06:47:14 +0000
Subject: [issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
In-Reply-To: <1509431344.9.0.213398074469.issue31909@psf.upfronthosting.co.za>
Message-ID: <1509432434.15.0.213398074469.issue31909@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is supposed to be handled by setup.py defining XML_POOR_ENTROTPY. Are you doing something non-standard?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31909>
_______________________________________

From report at bugs.python.org  Tue Oct 31 02:50:55 2017
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 31 Oct 2017 06:50:55 +0000
Subject: [issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
In-Reply-To: <1509431344.9.0.213398074469.issue31909@psf.upfronthosting.co.za>
Message-ID: <1509432655.68.0.213398074469.issue31909@psf.upfronthosting.co.za>


Ilya Kulakov <kulakov.ilya at gmail.com> added the comment:

Just compiling Python 3.6.3 from sources on Ubuntu 16.04

Is there any reason to fall back to XML_POOR_ENTROTPY when proper source is actually available?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31909>
_______________________________________

From report at bugs.python.org  Tue Oct 31 02:55:22 2017
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 31 Oct 2017 06:55:22 +0000
Subject: [issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
In-Reply-To: <1509431344.9.0.213398074469.issue31909@psf.upfronthosting.co.za>
Message-ID: <1509432922.46.0.213398074469.issue31909@psf.upfronthosting.co.za>


Ilya Kulakov <kulakov.ilya at gmail.com> added the comment:

nvm my last question.

My process is as per README: ./configure && make

I'll take a further look at what's wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31909>
_______________________________________

From report at bugs.python.org  Tue Oct 31 02:59:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 06:59:33 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509433173.04.0.213398074469.issue31629@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Victor and Pablo! Great work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 03:07:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 07:07:05 +0000
Subject: [issue31905] IPv4Networkcontains raises exception on None
In-Reply-To: <1509396968.75.0.213398074469.issue31905@psf.upfronthosting.co.za>
Message-ID: <1509433625.15.0.213398074469.issue31905@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur. IPvNetwork is not a general purposed collection. And even genera purposed collections can have restrictions on the arguments of "in". E.g.:

>>> [] in {}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Similar issue already was raised (maybe not for IPvNetwork, but for other class supporting the "in" operator) and was closed with the same arguments.

----------
nosy: +serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31905>
_______________________________________

From report at bugs.python.org  Tue Oct 31 03:07:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 07:07:23 +0000
Subject: [issue31905] IPv4Networkcontains raises exception on None
In-Reply-To: <1509396968.75.0.213398074469.issue31905@psf.upfronthosting.co.za>
Message-ID: <1509433643.84.0.213398074469.issue31905@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution: fixed -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31905>
_______________________________________

From report at bugs.python.org  Tue Oct 31 03:43:17 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 31 Oct 2017 07:43:17 +0000
Subject: [issue31907] Clarify error message when attempting to call function
 via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1509435797.39.0.213398074469.issue31907@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

How would you distinguish this from the case where an actually missing attribute was given?

>>> "{0.ctimex}".format(d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'datetime.datetime' object has no attribute 'ctimex'

I guess it would be possible to change the parser to only look for valid chars in an identifier and give an error if there were "extra" chars found, but I'm not sure it's worth the hassle. The error message seems clear enough to me. Also, I wouldn't want to change this to not be an AttributeError (for backward compatibility), and I'm not sure an AttributeError with a different message would be good.

Of course, this works with f-strings:

>>> f"{d.ctime()}"
'Tue Oct 31 00:00:00 2017'

And I just realized that your code actually is valid, with a custom __getattr__. And while I wouldn't recommend doing this, I also wouldn't want to break it. For all I know, people have written custom evaluators in __getattr__:

>>> class C:
...     def __getattr__(self, name):
...         if name == 'ctime()':
...             return 'okay'
...         raise AttributeError('not found')
...

>>> '{0.x}'.format(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __getattr__
AttributeError: not found

>>> '{0.ctime()}'.format(C())
'okay'

I'm changing versions because this would be a new feature, since it breaks valid code.

----------
assignee:  -> eric.smith
nosy: +eric.smith
status: open -> pending
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Tue Oct 31 04:12:37 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Oct 2017 08:12:37 +0000
Subject: [issue31901] atexit callbacks only called for current subinterpreter
In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za>
Message-ID: <1509437557.89.0.213398074469.issue31901@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Hmm, I don't think calling Py_Finalize in any interpreter other than the main one is actually defined at all, so I'm inclined to just make it an error, rather than trying to figure out how it should work. It would then be up to the embedding application to make sure it switched back to the main interpreter before calling Py_Finalize.

(We don't have this concern with Py_Initialize, since that *creates* the main interpreter)

----------
nosy: +eric.snow, grahamd

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31901>
_______________________________________

From report at bugs.python.org  Tue Oct 31 04:14:02 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Oct 2017 08:14:02 +0000
Subject: [issue31901] atexit callbacks only called for current subinterpreter
In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za>
Message-ID: <1509437642.06.0.213398074469.issue31901@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the main interpreter, Py_Finalize should be destroying all other subinterpreters as one of the first things it does, so if we're *not* currently doing that, it would make sense to fix it as part of Eric's subinterpreters PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31901>
_______________________________________

From report at bugs.python.org  Tue Oct 31 05:22:23 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 09:22:23 +0000
Subject: [issue30057] signal.signal should check tripped signals
In-Reply-To: <1492012349.83.0.519367248904.issue30057@psf.upfronthosting.co.za>
Message-ID: <1509441743.39.0.213398074469.issue30057@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30057>
_______________________________________

From report at bugs.python.org  Tue Oct 31 05:28:40 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 31 Oct 2017 09:28:40 +0000
Subject: [issue31901] atexit callbacks only called for current subinterpreter
In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za>
Message-ID: <1509442120.14.0.213398074469.issue31901@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

I don't have a reason to think Py_Finalize is not *destroying* the other subinterpreters. But it's not calling their atexit callbacks.

(Is there any reason Py_Finalize couldn't switch to the main interpreter itself? Assuming it's even necessary.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31901>
_______________________________________

From report at bugs.python.org  Tue Oct 31 05:46:06 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Oct 2017 09:46:06 +0000
Subject: [issue31901] atexit callbacks only called for current subinterpreter
In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za>
Message-ID: <1509443166.44.0.213398074469.issue31901@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I guess we allow an unhandled SystemExit in a child thread to propagate to (and hence terminate) the main thread, so allowing a Py_Finalize call in a subinterpreter to terminate the main interpreter would be comparable to that.

My main rationale for *requiring* that the main interpreter be active (or be made active) when shutting down is to reduce the number of scenarios we need to test (right now we only test Py_Initialize/Py_Finalize cycles with a single interpreter, and officially allowing finalization from arbitrary interpreters expands that test matrix a fair bit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31901>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:14:07 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 10:14:07 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509444847.66.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 19f68301a1295a9c30d9f28b8f1479cdcccd75aa by Victor Stinner in branch 'master':
bpo-31629: Add support.SaveSignals (#4183)
https://github.com/python/cpython/commit/19f68301a1295a9c30d9f28b8f1479cdcccd75aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:18:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 10:18:16 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509445096.81.0.213398074469.issue31629@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:20:35 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 10:20:35 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509445235.41.0.213398074469.issue31629@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4158

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:44:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 10:44:58 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509446698.38.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 1d481822a6295e6739da2d5cca0fdbede51fda22 by Victor Stinner in branch '2.7':
bpo-31629: Add support.SaveSignals (#4183) (#4188)
https://github.com/python/cpython/commit/1d481822a6295e6739da2d5cca0fdbede51fda22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:45:04 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 10:45:04 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509446704.1.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 41efc402f154e48e95dde2993901648edcb24069 by Victor Stinner in branch '3.6':
bpo-31629: Add support.SaveSignals (#4183) (#4187)
https://github.com/python/cpython/commit/41efc402f154e48e95dde2993901648edcb24069


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:45:56 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 10:45:56 +0000
Subject: [issue31629] Running test_curses on FreeBSD changes signal handlers
In-Reply-To: <1506673565.16.0.213398074469.issue31629@psf.upfronthosting.co.za>
Message-ID: <1509446756.85.0.213398074469.issue31629@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Thanks Serhiy Storchaka for the bug report and Pablo Galindo Salgado for the analysis!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31629>
_______________________________________

From report at bugs.python.org  Tue Oct 31 06:58:05 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Oct 2017 10:58:05 +0000
Subject: [issue31898] Add `recommended-packages.txt` to `venv` documentation
In-Reply-To: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>
Message-ID: <1509447485.53.0.213398074469.issue31898@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As part of this, a new subsection would be added to https://docs.python.org/devguide/stdlibchanges.html to document the process for adding new packages to the recommended packages list: propose them for standard library inclusion, and while "No" is still the most likely outcome, being added to the recommended packages list would be a potential middle ground for "Approved in principle, but the actual logistics of doing so probably don't work".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31898>
_______________________________________

From report at bugs.python.org  Tue Oct 31 07:01:46 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 11:01:46 +0000
Subject: [issue31852] Crashes with lines of the form "async \"
In-Reply-To: <1508786537.77.0.213398074469.issue31852@psf.upfronthosting.co.za>
Message-ID: <1509447706.87.0.213398074469.issue31852@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Would it also be the case for 'await' ?

"async" requires to maintain a "async_def" state. It seems like await doesn't need a state for itself, but rely on the "async_def" state which has been fixed.

Extract of Parser/tokenizer.c:

            /* Current token length is 5. */
            if (tok->async_def) {
                /* We're inside an 'async def' function. */
                if (memcmp(tok->start, "async", 5) == 0) {
                    return ASYNC;
                }
                if (memcmp(tok->start, "await", 5) == 0) {
                    return AWAIT;
                }
            }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31852>
_______________________________________

From report at bugs.python.org  Tue Oct 31 07:23:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 11:23:41 +0000
Subject: [issue31907] Clarify error message when attempting to call function
 via str.format()
In-Reply-To: <1509410120.18.0.213398074469.issue31907@psf.upfronthosting.co.za>
Message-ID: <1509449021.92.0.213398074469.issue31907@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have wrote a patch that change the parser to only accept valid identifiers. But now I have the same doubts and want first to discuss this [1]. This change can break the existing code as Eric's example shows.

[1] https://mail.python.org/pipermail/python-dev/2017-October/150052.html

----------
nosy: +serhiy.storchaka
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31907>
_______________________________________

From report at bugs.python.org  Tue Oct 31 07:31:37 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Oct 2017 11:31:37 +0000
Subject: [issue31898] Add a `recommended-packages.txt` file
In-Reply-To: <1509340647.27.0.213398074469.issue31898@psf.upfronthosting.co.za>
Message-ID: <1509449497.48.0.213398074469.issue31898@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thinking about it further, this list is actually going to be version independent, suggest it may actually belong somewhere outside the main documentation.

The Developer's Guide may be a reasonable stopgap measure until there's a better option available (e.g. if I ever get around to turning https://github.com/python/redistributor-guide/ into something more than a nearly empty repo)

----------
title: Add `recommended-packages.txt` to `venv` documentation -> Add a `recommended-packages.txt` file

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31898>
_______________________________________

From report at bugs.python.org  Tue Oct 31 07:56:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 11:56:46 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509451006.86.0.213398074469.issue31891@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset baac01e629d90f63dfde6b5cc433f4bc65c5feeb by Serhiy Storchaka in branch 'master':
bpo-31891: Fix building the curses module on NetBSD. (#4165)
https://github.com/python/cpython/commit/baac01e629d90f63dfde6b5cc433f4bc65c5feeb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Tue Oct 31 07:57:54 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 11:57:54 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509451074.17.0.213398074469.issue31891@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4159

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Tue Oct 31 07:59:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 11:59:57 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509451197.68.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b9052a0f91d2e83bbc27267247a5920c82b242a3 by Serhiy Storchaka in branch 'master':
bpo-31893: Fixed select.kqueue(). (#4166)
https://github.com/python/cpython/commit/b9052a0f91d2e83bbc27267247a5920c82b242a3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:01:04 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 12:01:04 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509451264.03.0.213398074469.issue31893@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4160

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:05:05 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 12:05:05 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509451505.13.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b484d5606ca76f9bbd0f5de7a6ef753400213e94 by Serhiy Storchaka in branch 'master':
bpo-31626: Fixed a bug in debug memory allocator. (#3844)
https://github.com/python/cpython/commit/b484d5606ca76f9bbd0f5de7a6ef753400213e94


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:05:55 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 12:05:55 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509451555.93.0.213398074469.issue31897@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset db91e0fe2417f075693a194a492b1699829871e7 by Serhiy Storchaka in branch 'master':
bpo-31897: Convert unexpected errors when read bogus binary plists into InvalidFileException. (#4171)
https://github.com/python/cpython/commit/db91e0fe2417f075693a194a492b1699829871e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:06:11 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 12:06:11 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509451571.51.0.213398074469.issue31626@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4161

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:07:10 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 12:07:10 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509451630.58.0.213398074469.issue31897@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4162

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:32:22 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 12:32:22 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509453142.15.0.213398074469.issue31893@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4163

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:33:11 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 12:33:11 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509453191.6.0.213398074469.issue31891@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5db32085e7e4d6be9a34d0a64ecf477eca224f15 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31891: Fix building the curses module on NetBSD. (GH-4165) (#4189)
https://github.com/python/cpython/commit/5db32085e7e4d6be9a34d0a64ecf477eca224f15


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:42:50 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 12:42:50 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509453770.7.0.213398074469.issue31891@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4164

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:46:17 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 12:46:17 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509453977.09.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f9a639b97c760f40d022223c7655053c89752850 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31893: Fixed select.kqueue(). (GH-4166) (#4190)
https://github.com/python/cpython/commit/f9a639b97c760f40d022223c7655053c89752850


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 08:48:18 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 12:48:18 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509454098.45.0.213398074469.issue31893@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

The commit b9052a0f91d2e83bbc27267247a5920c82b242a3 broke compilation on FreeBSD:

building 'select' extension
cc -pthread -fPIC -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include -I. -I/usr/local/include -I/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Include -I/usr/home/buildbot/python/3.x.koobs-freebsd10/build -c /usr/home/buildbot/python/3.x.koobs-freebsd10/build/Modules/selectmodule.c -o build/temp.freebsd-10.3-STABLE-amd64-3.7-pydebug/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Modules/selectmodule.o
/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Modules/selectmodule.c:1889:63: error: expected ';' at end of declaration
                FILTER_FMT_UNIT FLAGS_FMT_UNIT FFLAGS_FMT_UNIT DATA_FMT_UNIT
                                                              ^
                                                              ;
1 error generated.
*** WARNING: renaming "_asyncio" since importing it failed: No module named 'select'

http://buildbot.python.org/all/#/builders/87/builds/95/steps/3/logs/stdio

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 09:21:07 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 13:21:07 +0000
Subject: [issue31454] Include "import as" in tutorial
In-Reply-To: <1505317940.24.0.986048971751.issue31454@psf.upfronthosting.co.za>
Message-ID: <1509456067.76.0.213398074469.issue31454@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4165

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31454>
_______________________________________

From report at bugs.python.org  Tue Oct 31 09:58:37 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 13:58:37 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509458317.88.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset ece5659565e083baaee4d185ce181a98aaee7f96 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31626: Fixed a bug in debug memory allocator. (GH-3844) (#4191)
https://github.com/python/cpython/commit/ece5659565e083baaee4d185ce181a98aaee7f96


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 09:58:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 13:58:57 +0000
Subject: [issue31897] Unexpected exceptions in plistlib.loads
In-Reply-To: <1509336254.22.0.213398074469.issue31897@psf.upfronthosting.co.za>
Message-ID: <1509458337.57.0.213398074469.issue31897@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6969d368c43d4c97e5f7b7b22904305ec68f79ba by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31897: Convert unexpected errors when read bogus binary plists into InvalidFileException. (GH-4171) (#4192)
https://github.com/python/cpython/commit/6969d368c43d4c97e5f7b7b22904305ec68f79ba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31897>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:06:07 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 31 Oct 2017 14:06:07 +0000
Subject: [issue31901] atexit callbacks only called for current subinterpreter
In-Reply-To: <1509378283.18.0.213398074469.issue31901@psf.upfronthosting.co.za>
Message-ID: <1509458767.91.0.213398074469.issue31901@psf.upfronthosting.co.za>


Petr Viktorin <encukou at gmail.com> added the comment:

I'm not sure where the concept of "main subinterpreter" comes in, with respect to this issue.

I thnik the issue of atexit callbacks could be solved by something like keeping info about each callback's subinterpreter, and switching subinterpreters before running each one. I can see the locking needed for that being quite hairy, but independent of which thread calls all this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31901>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:12:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 14:12:38 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509459158.27.0.213398074469.issue31891@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e0fc1af67acb5684ae780128fbdb3c5419af51db by Serhiy Storchaka in branch '2.7':
[2.7] bpo-31891: Fix building the curses module on NetBSD. (GH-4165). (#4194)
https://github.com/python/cpython/commit/e0fc1af67acb5684ae780128fbdb3c5419af51db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:13:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 14:13:54 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509459234.38.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8cbf4e10646c3f5b8f0d274c2d7dea5bb6305f57 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-31893: Fixed select.kqueue(). (GH-4166) (#4193)
https://github.com/python/cpython/commit/8cbf4e10646c3f5b8f0d274c2d7dea5bb6305f57


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:18:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 14:18:30 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509459510.36.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Nathaniel: "(...) and numpy won't necessarily use this API anyway."

Can you elaborate why numpy wouldn't use this new API? I designed it with numpy in mind :-)

Using PyMem_AlignedAlloc() instead of using directly posix_memalign()/_aligned_alloc() provides the debug features for free:

* tracemalloc is able to trace memory allocations
* detect buffer underflow
* detect buffer overflow
* detect API misuse like PyMem_Free(PyMem_AlignedAlloc()) -- it doesn't detect free(PyMem_AlignedAlloc()) which is plain wrong on Windows (but this one should crash immediately ;-))

Other advantages:

* PyMem_AlignedAlloc(alignment, 0) is well defined: it never returns NULL
* PyMem_AlignedAlloc(alignment, size) checks on alignment value are the same on all operating systems

Moreover, Python takes care of the portability for you :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:23:42 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 14:23:42 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509459822.23.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Nathaniel Smith: "Given the complexities here, and that the Track/Untrack functions are public now, I do wonder if the actual aligned allocation routines should just be an internal API (i.e., not exposed in Python.h)."

I don't see why we would hide PyMem_AlignedAlloc() but requires to implement aligned_alloc in PyMem_SetAllocators().

The plan is also to slowly use PyMem_AlignedAlloc() internally for performance.

Can you elaborate the "complexities"? Do you mean that the proposed PyMem_AlignedAlloc() API is more complex than calling directly posix_memalign()?

PyMem_AlignedAlloc() is designed for performance. For best performances, CPUs require memory to be aligned on convenient values like powers of 2 ;-) I also understand that alignment must be a multiple of sizeof(void*) because CPU work on "CPU words". On a 64-bit CPU, a word is 8 bytes. If the memory is aligned on 4 bytes, it may have to fetch two words, you loose the advantage of memory alignment.

I understand that PyMem_AlignedAlloc() requirements come from the CPU arhcitecture, it's not an arbitrary limitation just for the fun ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:24:39 2017
From: report at bugs.python.org (William Ayd)
Date: Tue, 31 Oct 2017 14:24:39 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1509459879.78.0.213398074469.issue31844@psf.upfronthosting.co.za>


William Ayd <william.ayd at gmail.com> added the comment:

Would we be open to setting the meta class of the ParserBase to ABCMeta and setting error as an abstract method? That at the very least would make the expectation clearer for subclasses. 

I haven?t contributed to Python before but am open to this as a first attempt if the direction makes sense.

----------
nosy: +William Ayd

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:26:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 14:26:16 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509459976.6.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Stefan Krah: "we care about the C11 restriction? (...) "size - number of bytes to allocate. An integral multiple of alignment" (...) posix_memalign and _aligned_malloc don't care about the multiple."

I prefer to ignore this restriction at this point.

I wouldn't be surprised if posix_memalign() and _aligned_malloc() already align the size for us internally.

We can add the restriction later, if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:27:33 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 14:27:33 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509460053.12.0.213398074469.issue31893@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Oh, the commit also broke the "x86 Tiger 3.x buildbot:

http://buildbot.python.org/all/#/builders/30/builds/93

======================================================================
FAIL: test_create_event (test.test_kqueue.TestKQueue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_kqueue.py", line 71, in test_create_event
    self.assertEqual(ev.data, 5)
AssertionError: 25769803781 != 5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:38:03 2017
From: report at bugs.python.org (William Ayd)
Date: Tue, 31 Oct 2017 14:38:03 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1509460683.3.0.213398074469.issue31844@psf.upfronthosting.co.za>


William Ayd <william.ayd at gmail.com> added the comment:

And assuming that subclass requirement is intentional we could add an optional keyword argument to the HTMLParser that indicates what to do with errors, much like how encoding issues are handled within codecs. For backwards compatibility it can default to ignore, but fail and warn could be two alternate approaches that the error method could account for

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:40:30 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 14:40:30 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509460830.0.0.213398074469.issue31893@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +4166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:43:30 2017
From: report at bugs.python.org (John Brearley)
Date: Tue, 31 Oct 2017 14:43:30 +0000
Subject: [issue31880] subprocess process interaction with IDLEX GUI causes
 pygnuplot silent failures
In-Reply-To: <1509038618.41.0.213398074469.issue31880@psf.upfronthosting.co.za>
Message-ID: <1509461010.79.0.213398074469.issue31880@psf.upfronthosting.co.za>


John Brearley <brearley at bell.net> added the comment:

Additonal testing shows that the subprocess.run command will reliably interact directly with gnuplot, either from the IDLEX GUI or the Python terminal window.

import subprocess
def run_cmd(cmd):
   print("run_cmd cmd:", cmd)
   # MUST explicitly ask for stdout, stderr. timeout is in seconds
   p1 = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, timeout=20)
   # print("run_cmd p1:", p1, type(p1))
   print("run_cmd p1.stdout:", p1.stdout, type(p1.stdout), p1.stdout.decode("utf-8"))
   print("run_cmd p1.stderr:", p1.stderr, type(p1.stderr), p1.stderr.decode("utf-8"))
   print("run_cmd p1.returncode:", p1.returncode, type(p1.returncode))

cmd = "gnuplot.exe "+self+"_candles.gnu"
run_cmd(cmd)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31880>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:55:04 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 31 Oct 2017 14:55:04 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509461704.87.0.213398074469.issue18835@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> Can you elaborate why numpy wouldn't use this new API? I designed it with numpy in mind :-)

The reasons I had in mind are:

1) numpy hasn't actually come to a decision about whether to use aligned allocation at all, or under what circumstances.

2) if we do use it, we'll probably need our own implementation anyway to support old pythons.

3) also it's not clear what the best approach will look like, given that we care a lot about using calloc when possible, and have reason to prefer using regular freeing functions whenever possible.

I wasn't making a criticism of your API; "it's not you, it's us" :-). But this is a complicated and subtle area that's not really part of CPython's core competency, and coming at a time when people are fretting about how to shrink the C APIs surface area. E.g. I can think of more interesting ways for the PyPy folks to spend their time than implementing an aligned_alloc wrapper...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 10:56:12 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 14:56:12 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509461772.38.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oh, I forgot that Mac OS X also in the BSD family.

Thank you Victor for signaling errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 11:01:12 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Oct 2017 15:01:12 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1509461704.87.0.213398074469.issue18835@psf.upfronthosting.co.za>
Message-ID: <8391a847-e609-5df8-db5f-86411e63384c@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 31/10/2017 ? 15:55, Nathaniel Smith a ?crit?:
> 
> 1) numpy hasn't actually come to a decision about whether to use aligned allocation at all, or under what circumstances.

This isn't the Numpy bug tracker, but I can't help but mention that if
Numpy grew a facility for users to override the memory allocators it
invokes to allocate array data, Numpy may not have to come to a decision
about this at all... ;-) And it would also help specialized
accelerators, which may want to direct Numpy arrays to e.g. memory
that's cheaply shared with the GPU.

(see https://github.com/numpy/numpy/pull/5470)

> I wasn't making a criticism of your API; "it's not you, it's us" :-). But this is a complicated and subtle area that's not really part of CPython's core competency, and coming at a time when people are fretting about how to shrink the C APIs surface area. E.g. I can think of more interesting ways for the PyPy folks to spend their time than implementing an aligned_alloc wrapper...

The same argument can be made for any part of the stdlib or core
language that PyPy has to reproduce.  Besides, I don't think
implementing an aligned_alloc wrapper is very difficult.  The hard part
is getting an agreement over the exposed APIs, and that's CPython's job,
not PyPy ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 11:14:41 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 15:14:41 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1509461704.87.0.213398074469.issue18835@psf.upfronthosting.co.za>
Message-ID: <20171031151429.GA14078@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

On Tue, Oct 31, 2017 at 02:55:04PM +0000, Nathaniel Smith wrote:
> 3) also it's not clear what the best approach will look like, given that we care a lot about using calloc when possible, and have reason to prefer using regular freeing functions whenever possible.

I actually have the same problems. But since no fast (kernel-zeroed)
aligned_calloc() exists, I must use memset() anyway.

So an emulated aligned_calloc() should probably not go into CPython
since it doesn't provide any performance advantages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:08:44 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 16:08:44 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509466124.55.0.213398074469.issue20064@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4167

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:17:32 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 16:17:32 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509466652.58.0.213398074469.issue18835@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4168

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:18:24 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 16:18:24 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509466704.26.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2298fad5ff907dd48ea0fb5c71fa22334ef28c6b by Serhiy Storchaka in branch 'master':
bpo-31893: Fix errors in b9052a0f91d2e83bbc27267247a5920c82b242a3. (#4196)
https://github.com/python/cpython/commit/2298fad5ff907dd48ea0fb5c71fa22334ef28c6b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:19:31 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 16:19:31 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509466771.77.0.213398074469.issue31893@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4169

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:20:02 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 16:20:02 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509466802.96.0.213398074469.issue20064@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4170

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:20:34 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 16:20:34 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509466834.26.0.213398074469.issue31893@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4171

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:37:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 16:37:30 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509467850.2.0.213398074469.issue20064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset ec2cbdd1dff2c51788136480b2085e77506ebf34 by Victor Stinner in branch 'master':
bpo-20064: Document PyObject_Malloc() (#4199)
https://github.com/python/cpython/commit/ec2cbdd1dff2c51788136480b2085e77506ebf34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:38:42 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Oct 2017 16:38:42 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509467922.08.0.213398074469.issue20064@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4172

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:45:18 2017
From: report at bugs.python.org (John Brearley)
Date: Tue, 31 Oct 2017 16:45:18 +0000
Subject: [issue31880] subprocess process interaction with IDLEX GUI causes
 pygnuplot silent failures
In-Reply-To: <1509038618.41.0.213398074469.issue31880@psf.upfronthosting.co.za>
Message-ID: <1509468318.05.0.213398074469.issue31880@psf.upfronthosting.co.za>


John Brearley <brearley at bell.net> added the comment:

The owner of PyGnuplot figured out that for Python 3.4+ that a flush on stdin is needed. IDLEX GUI now runs example.py and my own test code correctly.

proc.stdin.flush()  # send the command in python 3.4+

This leaves the interesting behavior of IDLEX GUI. What is it doing differently re stdin from the command line terminal behavior? There is probably something to be learned here, if someone wants to dig into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31880>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:55:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 16:55:51 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509468951.47.0.213398074469.issue20064@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests: +4173

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 12:56:17 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 16:56:17 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509468977.89.0.213398074469.issue20064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 8543ce8ffd57d770b57fe653e0ab7fada1a4c343 by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-20064: Document PyObject_Malloc() (GH-4199) (#4203)
https://github.com/python/cpython/commit/8543ce8ffd57d770b57fe653e0ab7fada1a4c343


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 13:05:22 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 17:05:22 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
Message-ID: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

On my PR 4200 which is unrelated to networking, the following test failed once.

FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_socket.py", line 4537, in test_create_connection
    self.assertIn(cm.exception.errno, expected_errnos)
AssertionError: 99 not found in [111, 101]


With error codes:

* 99: EADDRNOTAVAIL: Cannot assign requested address
* 111: ECONNREFUSED: Connection refused
* 101: ENETUNREACH: Network is unreachable

Maybe we shold include EADDRNOTAVAIL in the expected error codes?

----------
components: Tests
messages: 305316
nosy: haypo, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_socket.test_create_connection() failed with EADDRNOTAVAIL (err 99)
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 13:05:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 17:05:57 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509469557.49.0.213398074469.issue20064@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
pull_requests:  -4170

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 13:08:31 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 17:08:31 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509469711.0.0.213398074469.issue20064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 52ba7b447f41dad2754ddbc50ed97413b557bbe1 by Victor Stinner in branch '2.7':
bpo-20064: Document PyObject_Malloc() (#4204)
https://github.com/python/cpython/commit/52ba7b447f41dad2754ddbc50ed97413b557bbe1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 13:09:18 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 17:09:18 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1509469758.37.0.213398074469.issue20064@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

It took a while, but PyObject_Malloc() & cie are now documented :-)

I even backported and *adapted* the doc to Python 2.7 ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Oct 31 13:57:44 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 17:57:44 +0000
Subject: [issue31911] Use malloc_usable_size() is pymalloc for realloc
Message-ID: <1509472664.46.0.213398074469.issue31911@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Objects/obmalloc.c contains an interesting comment:

    if (!address_in_range(p, pool)) {
        /* pymalloc is not managing this block.

           If nbytes <= SMALL_REQUEST_THRESHOLD, it's tempting to try to take
           over this block.  However, if we do, we need to copy the valid data
           from the C-managed block to one of our blocks, and there's no
           portable way to know how much of the memory space starting at p is
           valid.

           As bug 1185883 pointed out the hard way, it's possible that the
           C-managed block is "at the end" of allocated VM space, so that a
           memory fault can occur if we try to copy nbytes bytes starting at p.
           Instead we punt: let C continue to manage this block. */
        return 0;
    }

See also bpo-1185883.

We don't have to guess, it's possible to get the size of a memory block allocated by malloc() with:

* malloc_usable_size(ptr): available at least on Linux
* _msize(ptr): Windows

Maybe we could add a "msize" field to PyMemAllocatorEx? See also bpo-18835 whic adds PyMem_AlignedAlloc() and so already modify (and rename PyMemAllocatorEx).

See also bpo-31626, but I'm not sure that it would help for _PyMem_DebugRawRealloc().

----------
components: Interpreter Core
messages: 305319
nosy: haypo, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Use malloc_usable_size() is pymalloc for realloc
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31911>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:01:35 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 18:01:35 +0000
Subject: [issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
Message-ID: <1509472895.95.0.213398074469.issue31912@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan at bytereef.org>:

This is related to #27987 and #20064 and perhaps the pymalloc patch
from #18835.

I think PyMem_Malloc() should guarantee alignof(max_align_t).

It actually did before the "#define PYMEM_FUNCS PYOBJ_FUNCS" optimization,
so we have a sort of regression here.

----------
components: Interpreter Core
messages: 305320
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: PyMem_Malloc() should guarantee alignof(max_align_t)
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31912>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:02:09 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 18:02:09 +0000
Subject: [issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
In-Reply-To: <1509472895.95.0.213398074469.issue31912@psf.upfronthosting.co.za>
Message-ID: <1509472929.54.0.213398074469.issue31912@psf.upfronthosting.co.za>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31912>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:04:44 2017
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 31 Oct 2017 18:04:44 +0000
Subject: [issue31909] Missing definition of HAVE_SYSCALL_GETRANDOM
In-Reply-To: <1509431344.9.0.213398074469.issue31909@psf.upfronthosting.co.za>
Message-ID: <1509473084.31.0.213398074469.issue31909@psf.upfronthosting.co.za>


Ilya Kulakov <kulakov.ilya at gmail.com> added the comment:

Not a bug in Python.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31909>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:07:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 18:07:15 +0000
Subject: [issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
In-Reply-To: <1509472895.95.0.213398074469.issue31912@psf.upfronthosting.co.za>
Message-ID: <1509473235.53.0.213398074469.issue31912@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> I think PyMem_Malloc() should guarantee alignof(max_align_t).

Do you mean the C++ std::max_align_t? Does C99 have something like that?

The Linux malloc() manual page says:

"The malloc() and calloc() functions return a pointer to  the  allocated memory,  which  is  suitably  aligned for any built-in type."

But I don't know the list of C built-in types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31912>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:12:26 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 31 Oct 2017 18:12:26 +0000
Subject: [issue31913] forkserver could warn if several threads are running
Message-ID: <1509473546.78.0.213398074469.issue31913@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I'm not sure this is worth handling, but I had an interaction with a user who had weird deadlock problems in a glibc function (getaddrinfo) in worker processes launched with the forkserver method.

The explanation turned out to be that a sitecustomize.py did some stuff that eventually launched a helper thread, and that made the forkserver process's forking fundamentally unsafe (fork() is guaranteed to be safe if there's only one thread running in the parent process).

It would be easy to check that threading.enumerate() returns only one thread, and otherwise warn the user about it.  Note this only handles Python threads and not C threads invisible to Python... (a more complete solution would involve psutil :-)).

----------
components: Library (Lib)
messages: 305323
nosy: davin, gregory.p.smith, pitrou
priority: low
severity: normal
status: open
title: forkserver could warn if several threads are running
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31913>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:14:43 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 18:14:43 +0000
Subject: [issue31912] PyMem_Malloc() should guarantee alignof(max_align_t)
In-Reply-To: <1509473235.53.0.213398074469.issue31912@psf.upfronthosting.co.za>
Message-ID: <20171031181432.GA5095@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> Do you mean the C++ std::max_align_t? Does C99 have something like that?
> 
> The Linux malloc() manual page says:
> 
> "The malloc() and calloc() functions return a pointer to  the  allocated memory,  which  is  suitably  aligned for any built-in type."

C11 has max_align_t, but also for C99 "any builtin type" means 16 byte alignment
for long double on x64, so malloc() and calloc() are required to align 16 bytes
with -std=c99 (and earlier).

max_align_t is just a shorthand to express the concept.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31912>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:16:10 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 18:16:10 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509473770.03.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 84e252b79eed94bc9e9175f82191322c89e489ad by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
bpo-31893: Fix errors in b9052a0f91d2e83bbc27267247a5920c82b242a3. (GH-4196) (#4201)
https://github.com/python/cpython/commit/84e252b79eed94bc9e9175f82191322c89e489ad


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:16:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 18:16:13 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509473773.91.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e7531e54bf195b8d3ed35b4138901c82f7ed794c by Serhiy Storchaka (Miss Islington (bot)) in branch '2.7':
bpo-31893: Fix errors in b9052a0f91d2e83bbc27267247a5920c82b242a3. (GH-4196) (#4202)
https://github.com/python/cpython/commit/e7531e54bf195b8d3ed35b4138901c82f7ed794c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:26:17 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 31 Oct 2017 18:26:17 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509474377.77.0.213398074469.issue18835@psf.upfronthosting.co.za>


Nathaniel Smith <njs at pobox.com> added the comment:

> But since no fast (kernel-zeroed) aligned_calloc() exists, I must use memset() anyway. 

For large allocations, you'll probably be better off implementing your own aligned allocator on top of calloc than implementing your own calloc on top of an aligned allocator. (It's O(1) overhead versus O(n).) And once you're doing that you might want to use the same code for regular allocations too, so that you don't need to keep track of whether each memory block used aligned_calloc or aligned_malloc and can treat them the same... Depends on your exact circumstances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 14:53:43 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 31 Oct 2017 18:53:43 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509476023.95.0.213398074469.issue31630@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Seems the first result is calculated at compile time

Makes sense. Last time I looked, gcc uses MPFR for the compile-time calls, so I'd expect those to be correctly rounded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:07:08 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 19:07:08 +0000
Subject: [issue31893] Issues with kqueue
In-Reply-To: <1509277481.96.0.213398074469.issue31893@psf.upfronthosting.co.za>
Message-ID: <1509476828.8.0.213398074469.issue31893@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tests on all buildbots are passed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31893>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:14:33 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 19:14:33 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509477273.86.0.213398074469.issue31630@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

So the big mystery is still:

   https://mail.python.org/pipermail/python-dev/2017-October/149880.html


Could be a Linux router with some alternative libc ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:18:13 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Oct 2017 19:18:13 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509477493.87.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 9ed83c40855b57c10988f76770a4eb825e034cd8 by Victor Stinner in branch 'master':
bpo-18835: Cleanup pymalloc (#4200)
https://github.com/python/cpython/commit/9ed83c40855b57c10988f76770a4eb825e034cd8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:23:23 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 19:23:23 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509477803.52.0.213398074469.issue31626@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have removed the incorrect code in master and 3.6, this unblocks testing debug build on OpenBSD. I don't think it is worth to backport this change to 3.5 and 3.4, since the bug affects only debug build.

Here is a patch which perhaps is an alternative to PR 4119, but without disturbing the heap allocator. It erases just few bytes at the begin and at the end of the allocated block (including the header and the trailer), and saves erased bytes in small local buffer. It does this even if the block is not reallocated in-place. Hence calling free() on reallocated block will be detected. Reading from the reallocated block will get erased bytes at the start and the end, this is likely will cause to loud failure too. I have tested in on OpenBSD.

But I'm not sure that it is worth to apply this patch. Left it on to you Victor.

----------
versions:  -Python 3.4, Python 3.5
Added file: https://bugs.python.org/file47249/debug-realloc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:32:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 19:32:00 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1506675027.54.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <1509478320.65.0.213398074469.issue31630@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

>From 4 considered results the tests are failed on gcc 4.2.1, 4.7.2, 4.8.5, but are passes on gcc 7.2.0. I suppose this is gcc or libc bug fixed in recent versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:32:09 2017
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 31 Oct 2017 19:32:09 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509478329.84.0.213398074469.issue31626@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

> Most, if not all, calls to _PyMem_DebugRawRealloc() are protected by
> the GIL. If there is a single thread using the memory block,
> I think that it's perfectly fine to write after it's deallocated.

I don't quite follow where the write-after-free is happening, but: C's free() function is *not* protected by the GIL.  So if you're running in a multithreaded program where other threads aren't blocked by the GIL, one of these other threads could very easily allocate this freshly-freed memory.  And if you wrote to it after the memory was allocated to this other thread, congrats, your program is no longer correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:34:19 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 19:34:19 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509478459.92.0.213398074469.issue31626@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:43:00 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 19:43:00 +0000
Subject: [issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and
 NetBSD
In-Reply-To: <1509478320.65.0.213398074469.issue31630@psf.upfronthosting.co.za>
Message-ID: <20171031194248.GA6651@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

On Tue, Oct 31, 2017 at 07:32:00PM +0000, Serhiy Storchaka wrote:
> >>From 4 considered results the tests are failed on gcc 4.2.1, 4.7.2, 4.8.5, but are passes on gcc 7.2.0. I suppose this is gcc or libc bug fixed in recent versions.

4.7.3 passes here with -m32.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31630>
_______________________________________

From report at bugs.python.org  Tue Oct 31 15:58:54 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 19:58:54 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
In-Reply-To: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>
Message-ID: <1509479934.47.0.213398074469.issue31910@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm not a networking but it seems reasonable. If I understand correctly, EADDRNOTAVAIL can be raised on the Travis CI when a large number of network connections are created simultaneously by other CI tests.

Or maybe just repeat the test if EADDRNOTAVAIL is raised?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 16:02:42 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 20:02:42 +0000
Subject: [issue31844] HTMLParser: undocumented not implemented method
In-Reply-To: <1508747243.44.0.213398074469.issue31844@psf.upfronthosting.co.za>
Message-ID: <1509480162.21.0.213398074469.issue31844@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Library (Lib)
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31844>
_______________________________________

From report at bugs.python.org  Tue Oct 31 16:04:32 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Oct 2017 20:04:32 +0000
Subject: [issue31891] Make curses compiling on NetBSD 7.1 and tests passing
In-Reply-To: <1509268888.25.0.213398074469.issue31891@psf.upfronthosting.co.za>
Message-ID: <1509480272.87.0.213398074469.issue31891@psf.upfronthosting.co.za>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31891>
_______________________________________

From report at bugs.python.org  Tue Oct 31 16:45:13 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Tue, 31 Oct 2017 20:45:13 +0000
Subject: [issue31914] Document Pool.(star)map return type
Message-ID: <1509482713.68.0.213398074469.issue31914@psf.upfronthosting.co.za>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.starmap says:

starmap(func, iterable[, chunksize])
Like map() except that the elements of the iterable are expected to be iterables that are unpacked as arguments.

Hence an iterable of [(1,2), (3, 4)] results in [func(1,2), func(3,4)].



If it was like map() then it would have returned an iterator.  Please clarify, that Pool.map and Pool.starmap return list.

----------
assignee: docs at python
components: Documentation
messages: 305337
nosy: dilyan.palauzov, docs at python
priority: normal
severity: normal
status: open
title: Document Pool.(star)map return type
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31914>
_______________________________________

From report at bugs.python.org  Tue Oct 31 16:48:05 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Tue, 31 Oct 2017 20:48:05 +0000
Subject: [issue31914] Document Pool.(star)map return type
In-Reply-To: <1509482713.68.0.213398074469.issue31914@psf.upfronthosting.co.za>
Message-ID: <1509482885.78.0.213398074469.issue31914@psf.upfronthosting.co.za>


????? ???????? <dilyan.palauzov at aegee.org> added the comment:

Pool.starmap is not like map from the standard library, as the hyperlinking on the word map() suggests, but like Pool.map().  The latter talks about the chunksize parameter, but the former and Pool.starmap don't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31914>
_______________________________________

From report at bugs.python.org  Tue Oct 31 16:57:50 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Oct 2017 20:57:50 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1509474377.77.0.213398074469.issue18835@psf.upfronthosting.co.za>
Message-ID: <20171031205738.GA7005@bytereef.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> For large allocations, you'll probably be better off implementing your own aligned allocator on top of calloc than implementing your own calloc on top of an aligned allocator. (It's O(1) overhead versus O(n).) And once you're doing that you might want to use the same code for regular allocations too, so that you don't need to keep track of whether each memory block used aligned_calloc or aligned_malloc and can treat them the same... Depends on your exact circumstances.

Yes, but if the whole array is initialized with actual values, then
the memset() overhead is not very large (something like 16% here).

If uninitialized (or very sparse), the overhead is of course gigantic.

What is more, in some crude tests the posix_memalign() performance isn't
that great compared to malloc()/calloc().

C11 aligned_alloc() is also quite a bit faster than posix_memalign() here.

I think you're right that a hand-rolled solution on top of calloc() is
best for my use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 17:24:40 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 Oct 2017 21:24:40 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1509485080.52.0.213398074469.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For this idea to be revived, someone should write a PEP and open a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23551>
_______________________________________

From report at bugs.python.org  Tue Oct 31 18:46:10 2017
From: report at bugs.python.org (Michael Selik)
Date: Tue, 31 Oct 2017 22:46:10 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1509489970.24.0.213398074469.issue31908@psf.upfronthosting.co.za>


Michael Selik <michael.selik at gmail.com> added the comment:

The problem appears to be a mistake in commit f026dae130bf6f9015c4b212f16852ba4a3f3dec

https://github.com/python/cpython/commit/f026dae130bf6f9015c4b212f16852ba4a3f3dec

This made the writing of cover files conditional on ``show_missing`` which is the option to mark lines which weren't executed with several angle brackets ">>>>>".

https://github.com/python/cpython/blob/3.5/Lib/trace.py#L326

    mike on mac in ~/
    $ python -m trace --count foo.py
    hello

    mike on mac in ~/
    $ ls *.cover
    ls: *.cover: No such file or directory

    mike on mac in ~/
    $ python -m trace --count -m foo.py
    hello

    mike on mac in ~/
    $ ls *.cover
    -rw-r--r--  1 mike  staff    22B Oct 31 15:40 foo.cover

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Tue Oct 31 19:00:18 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 31 Oct 2017 23:00:18 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1509490818.79.0.213398074469.issue27051@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Tue Oct 31 19:00:47 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 31 Oct 2017 23:00:47 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1509490847.39.0.213398074469.issue23551@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23551>
_______________________________________

From report at bugs.python.org  Tue Oct 31 20:23:12 2017
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 01 Nov 2017 00:23:12 +0000
Subject: [issue14574] SocketServer doesn't handle client disconnects properly
In-Reply-To: <1334358462.67.0.980544384901.issue14574@psf.upfronthosting.co.za>
Message-ID: <1509495792.75.0.213398074469.issue14574@psf.upfronthosting.co.za>


Matej Cepl <mcepl at redhat.com> added the comment:

The last patch (clear_buffer_on_error.patch) has still not been applied (looking at 2.7 and master branches).

----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14574>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:10:39 2017
From: report at bugs.python.org (Michael Selik)
Date: Wed, 01 Nov 2017 01:10:39 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1509498639.43.0.213398074469.issue31908@psf.upfronthosting.co.za>


Michael Selik <michael.selik at gmail.com> added the comment:

While writing a patch for this, I noticed the ``lnotab`` parameter seems nearly unused. It's a dict, but is only used for its keys.

https://github.com/python/cpython/blob/master/Lib/trace.py#L333

Further, the choice to count unreached lines only when ``show_missing`` was set seems inconsistent.

https://github.com/python/cpython/blob/master/Lib/trace.py#L335

https://github.com/python/cpython/blob/master/Lib/trace.py#L280

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:13:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:13:19 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509498799.6.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

I merged my PR 4199 (Document PyObject_Malloc()) and PR 4200 (Cleanup pymalloc) to prepare PR 4089.

PR 4089 should now be completed and well tested.

The real question is now if we need PyMem_AlignedAlloc()?

Stefan Krah and Nathaniel Smith are interested by aligned memory allocations, but both wrote that they don't plan to use PyMem_AlignedAlloc() if I understood correctly. What's the point of adding PyMem_AlignedAlloc() in that case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:13:44 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:13:44 +0000
Subject: [issue18835] Add PyMem_AlignedAlloc()
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509498824.92.0.213398074469.issue18835@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Add aligned memory variants to the suite of PyMem functions/macros -> Add PyMem_AlignedAlloc()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:15:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:15:55 +0000
Subject: [issue18835] Add PyMem_AlignedAlloc()
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1509498954.99.0.213398074469.issue18835@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

msg196194: Antoine Pitrou: "Note that the current small object allocator, if not disabled, *should* already return you aligned memory, by construction (each allocation size has dedicated pools from which memory blocks are carved)."

In my current implementation of _PyObject_AlignedAlloc(), I only call pymalloc_alloc() for alignment <= pymalloc ALIGNMENT. Maybe we can do better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18835>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:30:20 2017
From: report at bugs.python.org (Chance Parsons)
Date: Wed, 01 Nov 2017 01:30:20 +0000
Subject: [issue31915] (list).insert() not working
Message-ID: <1509499820.34.0.213398074469.issue31915@psf.upfronthosting.co.za>


Change by Chance Parsons <chancelorne at icloud.com>:


----------
files: Times Tables.py
nosy: Chance Parsons
priority: normal
severity: normal
status: open
title: (list).insert() not working
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47250/Times Tables.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31915>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:38:25 2017
From: report at bugs.python.org (Michael Selik)
Date: Wed, 01 Nov 2017 01:38:25 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1509500305.58.0.213398074469.issue31908@psf.upfronthosting.co.za>


Change by Michael Selik <mike at selik.org>:


----------
keywords: +patch
pull_requests: +4174
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:43:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:43:11 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
In-Reply-To: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>
Message-ID: <1509500591.7.0.213398074469.issue31910@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
pull_requests: +4175
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:43:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:43:59 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
In-Reply-To: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>
Message-ID: <1509500639.45.0.213398074469.issue31910@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

> Or maybe just repeat the test if EADDRNOTAVAIL is raised?

I don't think that it's worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:51:48 2017
From: report at bugs.python.org (Michael Selik)
Date: Wed, 01 Nov 2017 01:51:48 +0000
Subject: [issue31908] trace module cli does not write cover files
In-Reply-To: <1509418506.94.0.213398074469.issue31908@psf.upfronthosting.co.za>
Message-ID: <1509501108.73.0.213398074469.issue31908@psf.upfronthosting.co.za>


Michael Selik <michael.selik at gmail.com> added the comment:

Ok, pull request submitted:
https://github.com/python/cpython/pull/4205

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31908>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:53:44 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:53:44 +0000
Subject: [issue31890] Please define the flag METH_STACKLESS for Stackless
 Python
In-Reply-To: <1509210414.45.0.213398074469.issue31890@psf.upfronthosting.co.za>
Message-ID: <1509501224.87.0.213398074469.issue31890@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

Hi Anselm,

What is the status of Stackless Python? I didn't hear about Stackless for 5 years. Is the project still alive?

I see some activity on https://bitbucket.org/stackless-dev/stackless/wiki/Home and http://www.stackless.com/pipermail/stackless/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31890>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:56:15 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 01:56:15 +0000
Subject: [issue31626] Writing in freed memory in _PyMem_DebugRawRealloc()
 after shrinking a memory block
In-Reply-To: <1506666550.42.0.213398074469.issue31626@psf.upfronthosting.co.za>
Message-ID: <1509501375.43.0.213398074469.issue31626@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:

While the commit b484d5606ca76f9bbd0f5de7a6ef753400213e94 fixes a crash on OpenBSD and makes the code "correct" on any platforms, I still see it as a feature regression. Detecting buffer overflow and using freed memory are feature of debug hooks.

https://docs.python.org/dev/c-api/memory.html#c.PyMem_SetupDebugHooks

So yes, debug-realloc.diff is interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31626>
_______________________________________

From report at bugs.python.org  Tue Oct 31 21:58:01 2017
From: report at bugs.python.org (Michael Selik)
Date: Wed, 01 Nov 2017 01:58:01 +0000
Subject: [issue31915] (list).insert() not working
Message-ID: <1509501481.07.0.213398074469.issue31915@psf.upfronthosting.co.za>


New submission from Michael Selik <michael.selik at gmail.com>:

What behavior did you expect from your code?
What behavior did you get instead?

It looks like you're not calling the list copy method correctly. Try writing "tables2.copy()" instead of "tables2.copy". It also looks like you have other bugs in your code.

This forum is for reporting bugs in the Python language. If you'd like help with bugs in your own code, try asking on StackOverflow (https://stackoverflow.com/) or on the Python Help mailing list (https://mail.python.org/mailman/listinfo/python-help).

----------
nosy: +Michael Selik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31915>
_______________________________________

From report at bugs.python.org  Tue Oct 31 22:08:45 2017
From: report at bugs.python.org (multimiler)
Date: Wed, 01 Nov 2017 02:08:45 +0000
Subject: [issue31916] ensurepip not honoring value of $(DESTDIR) - pip not
 installed
Message-ID: <1509502125.3.0.213398074469.issue31916@psf.upfronthosting.co.za>


New submission from multimiler <reid.madsen at me.com>:

I am building python from source for installation at /opt/python-3.6.3.  The result of the build will be installed in /somewhere/deb-pkg-build-dir.  I configure, build, and install, the package as follows:

./configure --prefix=/opt/python-$VER --enable-optimizations --with-ensurepip=install
make
make install DESTDIR=/somewhere/deb-pkg-build-dir

At the very end of the build log I find:

Requirement already satisfied: setuptools in /opt/python-3.6.3/lib/python3.6/site-packages

As a result PIP is not installed.  This is an error.  The pip installation process should be looking in $(DESTDIR)/opt/python-3.6.3.  Instead it is looking at /opt/python-3.6.3/... which is the python installation on the current build host -- NOT INSTALLED BY THIS BUILD.

In the top-level Makefile.pre I find the following that runs ensurepip to install pip:

install:  commoninstall bininstall maninstall
        if test "x$(ENSUREPIP)" != "xno"  ; then \
                case $(ENSUREPIP) in \
                        upgrade) ensurepip="--upgrade" ;; \
                        install|*) ensurepip="" ;; \
                esac; \
                $(RUNSHARED) $(PYTHON_FOR_BUILD) -m ensurepip \
                        $$ensurepip --root=$(DESTDIR)/ ; \
        fi

As you can see $(DESTDIR) is passed into ensurepip, but it is never used when checking for pip existence.

----------
components: Installation
messages: 305351
nosy: multimiler
priority: normal
severity: normal
status: open
title: ensurepip not honoring value of $(DESTDIR) - pip not installed
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31916>
_______________________________________

From report at bugs.python.org  Tue Oct 31 22:27:00 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 02:27:00 +0000
Subject: [issue31917] Add time.CLOCK_PROF constant
Message-ID: <1509503220.89.0.213398074469.issue31917@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

The CLOCK_PROF clock is used internally by time.process_time(). It may be interesting to expose this constant if available.

----------
components: FreeBSD, Library (Lib)
messages: 305352
nosy: haypo, koobs
priority: normal
severity: normal
status: open
title: Add time.CLOCK_PROF constant
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31917>
_______________________________________

From report at bugs.python.org  Tue Oct 31 22:27:59 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 02:27:59 +0000
Subject: [issue31917] Add time.CLOCK_PROF constant
In-Reply-To: <1509503220.89.0.213398074469.issue31917@psf.upfronthosting.co.za>
Message-ID: <1509503279.4.0.213398074469.issue31917@psf.upfronthosting.co.za>


Change by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
pull_requests: +4176
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31917>
_______________________________________

From report at bugs.python.org  Tue Oct 31 22:48:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Nov 2017 02:48:16 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
In-Reply-To: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>
Message-ID: <1509504496.38.0.213398074469.issue31910@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at gmail.com> added the comment:


New changeset 280c22a82a6756e9caffef031c564fd98f1b50e7 by Victor Stinner in branch 'master':
Fix test_socket.test_create_connection() (#4206)
https://github.com/python/cpython/commit/280c22a82a6756e9caffef031c564fd98f1b50e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 22:48:37 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Nov 2017 02:48:37 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
In-Reply-To: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>
Message-ID: <1509504517.24.0.213398074469.issue31910@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 22:49:33 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Nov 2017 02:49:33 +0000
Subject: [issue31910] test_socket.test_create_connection() failed with
 EADDRNOTAVAIL (err 99)
In-Reply-To: <1509469522.6.0.213398074469.issue31910@psf.upfronthosting.co.za>
Message-ID: <1509504573.77.0.213398074469.issue31910@psf.upfronthosting.co.za>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +4178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31910>
_______________________________________

From report at bugs.python.org  Tue Oct 31 23:14:32 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Nov 2017 03:14:32 +0000
Subject: [issue18534] State clearly that open() 'file' param is "name" attr of
 the result
In-Reply-To: <1374556018.34.0.468152457131.issue18534@psf.upfronthosting.co.za>
Message-ID: <1509506072.95.0.213398074469.issue18534@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Agreed it's too subtle to change the behavior.

> We may also want to explicitly point out that using os.fsdecode(name) before passing it to open() will ensure that the name attribute is set to a string rather than a bytes object.

Not sure. Are there cases where os.fsdecode() fails even if the binary syscall would succeed? (The docs claim that on Windows it uses 'strict'.)

If it doesn't, maybe we can add a new attribute that gives the name as Text? It could be '' if name is an int.

----------
nosy: +gvanrossum
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18534>
_______________________________________

From report at bugs.python.org  Tue Oct 31 23:37:07 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 01 Nov 2017 03:37:07 +0000
Subject: [issue31915] (list).insert() not working
In-Reply-To: <1509501481.07.0.213398074469.issue31915@psf.upfronthosting.co.za>
Message-ID: <1509507427.16.0.213398074469.issue31915@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Thank you for taking the time to report what you thought was a bug, but your example is way too complicated for a bug report. We shouldn't have to study your entire program to understand what the problem is.

I can see at least one bug in your code:

    tbles = tables2.copy

sets the variable "tbles" as an alias to the "tables2.copy" method, and of course methods don't have an insert method themselves. So I'm closing this as "Not a bug". If you disagree, feel free to re-open the ticket with more information.

In future, please always report the SIMPLEST example of the bug that you can write. Tell us what you expected to happen, and COPY AND PASTE (no screenshots) the error message that you get, or other unexpected result.

You might also find it useful to read this page:

http://sscce.org/

It is written in terms of Java, but the principles apply equally to every programming language.

Thank you.

----------
nosy: +steven.daprano
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31915>
_______________________________________

From report at bugs.python.org  Tue Oct 31 23:37:48 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 01 Nov 2017 03:37:48 +0000
Subject: [issue31915] (list).insert() not working
In-Reply-To: <1509501481.07.0.213398074469.issue31915@psf.upfronthosting.co.za>
Message-ID: <1509507468.36.0.213398074469.issue31915@psf.upfronthosting.co.za>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31915>
_______________________________________